* Re: [PATCH v9 3/3] backlight arcxcnn add support for ArcticSand devices
From: Lee Jones @ 2017-04-25 8:19 UTC (permalink / raw)
To: Olimpiu Dejeu
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w, bdodge-eV7fy4qpoLhpLGFMi4vTTA,
joe-6d6DIl74uiNBDgjK7y7TUQ, medasaro-eV7fy4qpoLhpLGFMi4vTTA,
daniel.thompson-QSEj5FYQhm4dnm+yROfE0A,
lkp-ral2JQCrhuEAvxtiuMwx3w, fengguang.wu-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <1490115528-11044-3-git-send-email-olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
On Tue, 21 Mar 2017, Olimpiu Dejeu wrote:
> 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.
> Reviewed-by: Daniel Thompson <daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> ---
> v8 => v9:
> - Addressing kbuild test robot WARNING: PTR_ERR_OR_ZERO can be used
> v7 => v8:
> - Version updated to match other patch in set. No other changes.
> v6 => v7:
> - Addressing issues brought up by Daniel Thompson
> v5 => v6:
> - Addressing issues brought up by Daniel Thompson
> v4 => v5:
> - Code style changes per Joe Perches and Jingoo Han
> v3 => v4:
> - Code style changes per Joe Perches and Jingoo Han
> 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 | 419 +++++++++++++++++++++++++++++++++++
> 3 files changed, 427 insertions(+)
> create mode 100644 drivers/video/backlight/arcxcnn_bl.c
Applied this (and the correct (v9) version of [PATCH 2/3] too).
> 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..e01b1b0
> --- /dev/null
> +++ b/drivers/video/backlight/arcxcnn_bl.c
> @@ -0,0 +1,419 @@
> +/*
> + * 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>
> +
> +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;
> +};
> +
> +#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
> +#define INIT_BRIGHT 60
> +
> +struct arcxcnn {
> + struct i2c_client *client;
> + struct backlight_device *bl;
> + struct device *dev;
> + struct arcxcnn_platform_data *pdata;
> +};
> +
> +static int arcxcnn_update_field(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);
> + return i2c_smbus_write_byte_data(lp->client,
> + ARCXCNN_WLED_ISET_MSB, val);
> +}
> +
> +static int arcxcnn_bl_update_status(struct backlight_device *bl)
> +{
> + struct arcxcnn *lp = bl_get_data(bl);
> + u32 brightness = bl->props.brightness;
> + int ret;
> +
> + if (bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> + brightness = 0;
> +
> + ret = arcxcnn_set_brightness(lp, brightness);
> + if (ret)
> + return ret;
> +
> + /* set power-on/off/save modes */
> + return arcxcnn_update_field(lp, ARCXCNN_CMD, ARCXCNN_CMD_STDBY,
> + (bl->props.power == 0) ? 0 : ARCXCNN_CMD_STDBY);
> +}
> +
> +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;
> +
> + 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);
> + return PTR_ERR_OR_ZERO(lp->bl);
> +}
> +
> +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");
> + return;
> + }
> +
> + lp->pdata->leden = 0;
> +
> + /* for each enable in source, set bit in led enable */
> + for (entry = 0; entry < num_entry; entry++) {
> + u8 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;
> +
> + 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 */
> + ret = i2c_smbus_write_byte_data(lp->client,
> + ARCXCNN_CMD, ARCXCNN_CMD_RESET);
> + if (ret)
> + goto probe_err;
> +
> + 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 = INIT_BRIGHT;
> + lp->pdata->leden = ARCXCNN_LEDEN_MASK;
> +
> + 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 */
> + ret = arcxcnn_set_brightness(lp, lp->pdata->initial_brightness);
> + if (ret)
> + goto probe_err;
> +
> + /* set other register values directly */
> + ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_FADECTRL,
> + lp->pdata->led_config_0);
> + if (ret)
> + goto probe_err;
> +
> + ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_ILED_CONFIG,
> + lp->pdata->led_config_1);
> + if (ret)
> + goto probe_err;
> +
> + ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_DIMFREQ,
> + lp->pdata->dim_freq);
> + if (ret)
> + goto probe_err;
> +
> + ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_COMP_CONFIG,
> + lp->pdata->comp_config);
> + if (ret)
> + goto probe_err;
> +
> + ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_FILT_CONFIG,
> + lp->pdata->filter_config);
> + if (ret)
> + goto probe_err;
> +
> + ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_IMAXTUNE,
> + lp->pdata->trim_config);
> + if (ret)
> + goto probe_err;
> +
> + /* set initial LED Enables */
> + arcxcnn_update_field(lp, ARCXCNN_LEDEN,
> + ARCXCNN_LEDEN_MASK, lp->pdata->leden);
> +
> + ret = arcxcnn_backlight_register(lp);
> + if (ret)
> + goto probe_register_err;
> +
> + backlight_update_status(lp->bl);
> +
> + return 0;
> +
> +probe_register_err:
> + dev_err(lp->dev,
> + "failed to register backlight.\n");
> +
> +probe_err:
> + dev_err(lp->dev,
> + "failure ret: %d\n", ret);
> + return ret;
> +}
> +
> +static int arcxcnn_remove(struct i2c_client *cl)
> +{
> + struct arcxcnn *lp = i2c_get_clientdata(cl);
> +
> + /* disable all strings (ignore errors) */
> + i2c_smbus_write_byte_data(lp->client,
> + ARCXCNN_LEDEN, 0x00);
> + /* reset the device (ignore errors) */
> + i2c_smbus_write_byte_data(lp->client,
> + ARCXCNN_CMD, ARCXCNN_CMD_RESET);
> +
> + lp->bl->props.brightness = 0;
> +
> + backlight_update_status(lp->bl);
> +
> + 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");
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v8 2/3] backlight arcxcnn devicetree bindings for ArcticSand
From: Lee Jones @ 2017-04-25 8:17 UTC (permalink / raw)
To: Olimpiu Dejeu
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w, bdodge-eV7fy4qpoLhpLGFMi4vTTA,
joe-6d6DIl74uiNBDgjK7y7TUQ, medasaro-eV7fy4qpoLhpLGFMi4vTTA,
daniel.thompson-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1489607133-7870-2-git-send-email-olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
On Wed, 15 Mar 2017, Olimpiu Dejeu wrote:
> 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>
> Acked-by: Daniel Thompson <daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> ---
> v7 => v8:
> - Version updated to match other patch in set. No other changes.
> v6 => v7:
> - Version updated to match other patch in set. No other changes.
> v5 => v6:
> - Version updated to match other patch in set. No other changes.
> v4 => v5:
> - Added spaces for increased readability per Lee Jones
> v3 => v4:
> - Added spaces for increased readability per Lee Jones
> 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 | 33 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
Applied, thanks.
> 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..ecb7731
> --- /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>;
> +};
> +
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] mfd: max7360: Add mfd core device driver
From: Valentin Sitdikov @ 2017-04-25 8:15 UTC (permalink / raw)
To: lee.jones, robh+dt, mark.rutland, devicetree, linux-kernel
Cc: Andrei Dranitca, Valentin Sitdikov
In-Reply-To: <20170425081557.13941-1-valentin_sitdikov@mentor.com>
From: Andrei Dranitca <Andrei_Dranitca@mentor.com>
This patch adds core/irq driver to support MAX7360 i2c chip
which contains keypad, gpio, pwm, gpo and rotary encoder submodules.
Signed-off-by: Valentin Sitdikov <valentin_sitdikov@mentor.com>
Signed-off-by: Andrei Dranitca <Andrei_Dranitca@mentor.com>
---
drivers/mfd/Kconfig | 16 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/max7360.c | 393 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/max7360.h | 130 +++++++++++++++
4 files changed, 540 insertions(+)
create mode 100644 drivers/mfd/max7360.c
create mode 100644 include/linux/mfd/max7360.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 55ecdfb..2227c65 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -688,6 +688,22 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MAX7360
+ tristate "Maxim Semiconductor MAX7360 support"
+ depends on I2C && OF
+ select MFD_CORE
+ select REGMAP_I2C
+ select IRQ_DOMAIN
+ help
+ Say yes here to add support for Maxim Semiconductor MAX7360.
+ This provides microprocessors with management of up to 64 key switches,
+ with an additional eight LED drivers/GPIOs that feature constant-current,
+ PWM intensity control, and rotary switch control options.
+
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
config MFD_MT6397
tristate "MediaTek MT6397 PMIC Support"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 31ce076..f01f3a1 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -133,6 +133,7 @@ obj-$(CONFIG_MFD_DA9063) += da9063.o
obj-$(CONFIG_MFD_DA9150) += da9150-core.o
obj-$(CONFIG_MFD_MAX14577) += max14577.o
+obj-$(CONFIG_MFD_MAX7360) += max7360.o
obj-$(CONFIG_MFD_MAX77620) += max77620.o
obj-$(CONFIG_MFD_MAX77686) += max77686.o
obj-$(CONFIG_MFD_MAX77693) += max77693.o
diff --git a/drivers/mfd/max7360.c b/drivers/mfd/max7360.c
new file mode 100644
index 0000000..b4c2fdd
--- /dev/null
+++ b/drivers/mfd/max7360.c
@@ -0,0 +1,393 @@
+/*
+ * Copyright (C) 2017 Mentor Graphics
+ *
+ * Author: Valentin Sitdikov <Valentin.Sitdikov@mentor.com>
+ * Author: Andrei Dranitca <Andrei_Dranitca@mentor.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/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/max7360.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/slab.h>
+
+
+int max7360_request_pin(struct max7360 *max7360, u8 pin)
+{
+ struct i2c_client *client = max7360->i2c;
+ int ret = 0;
+
+ spin_lock(&max7360->lock);
+ if (max7360->gpio_pins & BIT(pin)) {
+ dev_err(&client->dev, "pin %d already requested, mask %x",
+ pin, max7360->gpio_pins);
+ spin_unlock(&max7360->lock);
+ return -EBUSY;
+ }
+ max7360->gpio_pins |= BIT(pin);
+ dev_dbg(&client->dev, "pin %d requested successfully", pin);
+ spin_unlock(&max7360->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(max7360_request_pin);
+
+void max7360_free_pin(struct max7360 *max7360, u8 pin)
+{
+ spin_lock(&max7360->lock);
+ max7360->gpio_pins &= ~BIT(pin);
+ spin_unlock(&max7360->lock);
+}
+EXPORT_SYMBOL_GPL(max7360_free_pin);
+
+static const struct mfd_cell max7360_devices[] = {
+ {
+ .name = "max7360-gpio",
+ .of_compatible = "maxim,max7360-gpio",
+ },
+ {
+ .name = "max7360-keypad",
+ .of_compatible = "maxim,max7360-keypad",
+ },
+ {
+ .name = "max7360-pwm",
+ .of_compatible = "maxim,max7360-pwm",
+ },
+ {
+ .name = "max7360-rotary",
+ .of_compatible = "maxim,max7360-rotary",
+ },
+};
+
+static irqreturn_t max7360_irq(int irq, void *data)
+{
+ struct max7360 *max7360 = data;
+ int virq;
+
+ virq = irq_find_mapping(max7360->domain, MAX7360_INT_GPIO);
+ handle_nested_irq(virq);
+ virq = irq_find_mapping(max7360->domain, MAX7360_INT_KEYPAD);
+ handle_nested_irq(virq);
+ virq = irq_find_mapping(max7360->domain, MAX7360_INT_ROTARY);
+ handle_nested_irq(virq);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t max7360_irqi(int irq, void *data)
+{
+ struct max7360 *max7360 = data;
+ int virq;
+
+ virq = irq_find_mapping(max7360->domain, MAX7360_INT_GPIO);
+ handle_nested_irq(virq);
+ virq = irq_find_mapping(max7360->domain, MAX7360_INT_ROTARY);
+ handle_nested_irq(virq);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t max7360_irqk(int irq, void *data)
+{
+ struct max7360 *max7360 = data;
+ int virq;
+
+ virq = irq_find_mapping(max7360->domain, MAX7360_INT_KEYPAD);
+ handle_nested_irq(virq);
+
+ return IRQ_HANDLED;
+}
+
+static int max7360_irq_map(struct irq_domain *d, unsigned int virq,
+ irq_hw_number_t hwirq)
+{
+ struct max7360 *max7360 = d->host_data;
+
+ irq_set_chip_data(virq, max7360);
+ irq_set_chip_and_handler(virq, &dummy_irq_chip,
+ handle_edge_irq);
+ irq_set_nested_thread(virq, 1);
+ irq_set_noprobe(virq);
+
+ return 0;
+}
+
+static void max7360_irq_unmap(struct irq_domain *d, unsigned int virq)
+{
+ irq_set_chip_and_handler(virq, NULL, NULL);
+ irq_set_chip_data(virq, NULL);
+}
+
+static const struct irq_domain_ops max7360_irq_ops = {
+ .map = max7360_irq_map,
+ .unmap = max7360_irq_unmap,
+ .xlate = irq_domain_xlate_onecell,
+};
+
+static int max7360_irq_init(struct max7360 *max7360, struct device_node *np)
+{
+ int ret;
+
+ max7360->inti = of_irq_get_byname(np, "inti");
+ max7360->intk = of_irq_get_byname(np, "intk");
+
+ if (max7360->inti < 0 || max7360->intk < 0) {
+ max7360->shared_irq = of_irq_get_byname(np, "int-shared");
+
+ if (max7360->shared_irq < 0) {
+ dev_err(max7360->dev, "failed to find IRQ in dts\n");
+ return -EINVAL;
+ }
+
+ ret = request_threaded_irq(max7360->shared_irq, NULL,
+ max7360_irq,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ "max7360", max7360);
+ if (ret) {
+ dev_err(max7360->dev, "failed to request IRQ: %d\n",
+ ret);
+ return ret;
+ }
+ } else {
+ max7360->shared_irq = 0;
+ ret = request_threaded_irq(max7360->inti, NULL, max7360_irqi,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ "max7360", max7360);
+ if (ret) {
+ dev_err(max7360->dev, "failed to request inti IRQ: %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = request_threaded_irq(max7360->intk, NULL, max7360_irqk,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ "max7360", max7360);
+ if (ret) {
+ free_irq(max7360->inti, max7360);
+ dev_err(max7360->dev, "failed to request intk IRQ: %d\n",
+ ret);
+ return ret;
+ }
+ }
+
+ max7360->domain = irq_domain_add_simple(np, MAX7360_NR_INTERNAL_IRQS,
+ 0, &max7360_irq_ops, max7360);
+
+ if (!max7360->domain) {
+ if (max7360->shared_irq)
+ free_irq(max7360->shared_irq, max7360);
+ else {
+ free_irq(max7360->inti, max7360);
+ free_irq(max7360->intk, max7360);
+ }
+ dev_err(max7360->dev, "Failed to create irqdomain\n");
+ return -ENODEV;
+ }
+
+ irq_create_mapping(max7360->domain, MAX7360_INT_GPIO);
+ irq_create_mapping(max7360->domain, MAX7360_INT_KEYPAD);
+ irq_create_mapping(max7360->domain, MAX7360_INT_ROTARY);
+
+ return 0;
+}
+
+void max7360_fall_deepsleep(struct max7360 *max7360)
+{
+ max7360_write_reg(max7360, MAX7360_REG_SLEEP, MAX7360_AUTOSLEEP_8192);
+}
+EXPORT_SYMBOL_GPL(max7360_fall_deepsleep);
+
+void max7360_take_catnap(struct max7360 *max7360)
+{
+ max7360_write_reg(max7360, MAX7360_REG_SLEEP, MAX7360_AUTOSLEEP_256);
+}
+EXPORT_SYMBOL_GPL(max7360_take_catnap);
+
+static int max7360_chip_init(struct max7360 *max7360)
+{
+ max7360->gpio_pins = MAX7360_MAX_GPIO;
+ max7360->gpo_count = 0;
+ max7360->col_count = MAX7360_COL_GPO_PINS;
+ return 0;
+}
+
+static int max7360_device_init(struct max7360 *max7360)
+{
+ int ret = 0;
+
+ ret = mfd_add_devices(max7360->dev, -1, max7360_devices,
+ ARRAY_SIZE(max7360_devices), NULL,
+ 0, max7360->domain);
+ if (ret)
+ dev_err(max7360->dev, "failed to add child devices\n");
+
+ return ret;
+}
+
+int max7360_request_gpo_pin_count(struct max7360 *max7360, u8 count)
+{
+ if (count > MAX7360_MAX_GPO)
+ return -EINVAL;
+ if (max7360->col_count + count > MAX7360_COL_GPO_PINS) {
+ dev_err(max7360->dev,
+ "trying to request %d pins as gpo while %d pins already used as COL\n",
+ count, max7360->col_count);
+ return -EINVAL;
+ }
+ max7360->gpo_count = count;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(max7360_request_gpo_pin_count);
+
+int max7360_request_col_count(struct max7360 *max7360, u8 count)
+{
+ if (max7360->gpo_count + count > MAX7360_COL_GPO_PINS) {
+ dev_err(max7360->dev,
+ "trying to request %d pins as COL while %d pins already used as gpo\n",
+ count, max7360->gpo_count);
+ return -EINVAL;
+ }
+ max7360->col_count = count;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(max7360_request_col_count);
+
+static const struct regmap_range max7360_volatile_ranges[] = {
+ {
+ .range_min = MAX7360_REG_KEYFIFO,
+ .range_max = MAX7360_REG_KEYFIFO,
+ }, {
+ .range_min = 0x48,
+ .range_max = 0x4a,
+ },
+};
+
+static const struct regmap_access_table max7360_volatile_table = {
+ .yes_ranges = max7360_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(max7360_volatile_ranges),
+};
+
+static const struct regmap_config max7360_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0xff,
+ .volatile_table = &max7360_volatile_table,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int max7360_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ struct device_node *np = i2c->dev.of_node;
+ struct max7360 *max7360;
+
+ int ret;
+
+ max7360 = devm_kzalloc(&i2c->dev, sizeof(struct max7360),
+ GFP_KERNEL);
+ if (!max7360)
+ return -ENOMEM;
+
+ spin_lock_init(&max7360->lock);
+
+ max7360->dev = &i2c->dev;
+ max7360->i2c = i2c;
+
+ i2c_set_clientdata(i2c, max7360);
+
+ max7360->regmap = devm_regmap_init_i2c(i2c, &max7360_regmap_config);
+ ret = max7360_chip_init(max7360);
+ if (ret)
+ return ret;
+
+ ret = max7360_irq_init(max7360, np);
+ if (ret)
+ return ret;
+
+ ret = max7360_device_init(max7360);
+ if (ret) {
+ dev_err(max7360->dev, "failed to add child devices\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int max7360_remove(struct i2c_client *client)
+{
+ struct max7360 *max7360 = i2c_get_clientdata(client);
+
+ mfd_remove_devices(max7360->dev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int max7360_suspend(struct device *dev)
+{
+ return 0;
+}
+
+static int max7360_resume(struct device *dev)
+{
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(max7360_dev_pm_ops, max7360_suspend, max7360_resume);
+
+static const struct of_device_id max7360_match[] = {
+ { .compatible = "maxim,max7360" },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, max7360_match);
+
+static const struct i2c_device_id max7360_id[] = {
+ { "max7360", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, max7360_id);
+
+static struct i2c_driver max7360_driver = {
+ .driver = {
+ .name = "max7360",
+ .pm = &max7360_dev_pm_ops,
+ .of_match_table = max7360_match,
+ },
+ .probe = max7360_probe,
+ .remove = max7360_remove,
+ .id_table = max7360_id,
+};
+
+static int __init max7360_init(void)
+{
+ return i2c_add_driver(&max7360_driver);
+}
+subsys_initcall(max7360_init);
+
+static void __exit max7360_exit(void)
+{
+ i2c_del_driver(&max7360_driver);
+}
+module_exit(max7360_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("MAX7360 MFD core driver");
diff --git a/include/linux/mfd/max7360.h b/include/linux/mfd/max7360.h
new file mode 100644
index 0000000..d139ddd
--- /dev/null
+++ b/include/linux/mfd/max7360.h
@@ -0,0 +1,130 @@
+#ifndef __LINUX_MFD_MAX7360_H
+#define __LINUX_MFD_MAX7360_H
+#include <linux/regmap.h>
+
+#define MAX7360_MAX_KEY_ROWS 8
+#define MAX7360_MAX_KEY_COLS 8
+#define MAX7360_MAX_KEY_NUM (MAX7360_MAX_KEY_ROWS * MAX7360_MAX_KEY_COLS)
+#define MAX7360_ROW_SHIFT 3
+
+#define MAX7360_MAX_GPIO 8
+#define MAX7360_MAX_GPO 6
+#define MAX7360_COL_GPO_PINS 8
+/*
+ * MAX7360 registers
+ */
+#define MAX7360_REG_KEYFIFO 0x00
+#define MAX7360_REG_CONFIG 0x01
+#define MAX7360_REG_DEBOUNCE 0x02
+#define MAX7360_REG_INTERRUPT 0x03
+#define MAX7360_REG_PORTS 0x04
+#define MAX7360_REG_KEYREP 0x05
+#define MAX7360_REG_SLEEP 0x06
+
+/*
+ * MAX7360 registers
+ */
+#define MAX7360_REG_GPIOCFG 0x40
+#define MAX7360_REG_GPIOCTRL 0x41
+#define MAX7360_REG_GPIODEB 0x42
+#define MAX7360_REG_GPIOCURR 0x43
+#define MAX7360_REG_GPIOOUTM 0x44
+#define MAX7360_REG_PWMCOM 0x45
+#define MAX7360_REG_RTRCFG 0x46
+#define MAX7360_REG_GPIOIN 0x49
+#define MAX7360_REG_RTR_CNT 0x4A
+#define MAX7360_REG_PWMBASE 0x50
+#define MAX7360_REG_PWMCFG 0x58
+
+
+#define MAX7360_REG_PORTCFGBASE 0x58
+
+/*
+ * Configuration register bits
+ */
+#define MAX7360_CFG_SLEEP (1 << 7)
+#define MAX7360_CFG_INTERRUPT (1 << 5)
+#define MAX7360_CFG_KEY_RELEASE (1 << 3)
+#define MAX7360_CFG_WAKEUP (1 << 1)
+#define MAX7360_CFG_TIMEOUT (1 << 0)
+
+/*
+ * Autosleep register values (ms)
+ */
+#define MAX7360_AUTOSLEEP_8192 0x01
+#define MAX7360_AUTOSLEEP_4096 0x02
+#define MAX7360_AUTOSLEEP_2048 0x03
+#define MAX7360_AUTOSLEEP_1024 0x04
+#define MAX7360_AUTOSLEEP_512 0x05
+#define MAX7360_AUTOSLEEP_256 0x06
+
+#define MAX7360_INT_INTI 0
+#define MAX7360_INT_INTK 1
+
+#define MAX7360_INT_GPIO 0
+#define MAX7360_INT_KEYPAD 1
+#define MAX7360_INT_ROTARY 2
+
+#define MAX7360_NR_INTERNAL_IRQS 3
+
+struct max7360 {
+ spinlock_t lock; /* lock access to the structure */
+ struct device *dev;
+ struct i2c_client *i2c;
+ struct irq_domain *domain;
+ struct regmap *regmap;
+
+ int irq_base;
+ int num_gpio;
+ int shared_irq;
+ int inti;
+ int intk;
+ u8 gpio_pins;
+ u8 col_count;
+ u8 gpo_count;
+};
+
+static inline int max7360_read_reg(struct max7360 *max7360, int reg)
+{
+ unsigned int ival;
+ int ret;
+
+ ret = regmap_read(max7360->regmap, reg, &ival);
+ if (!ret)
+ return ival;
+ return 0;
+}
+
+static inline int max7360_write_reg(struct max7360 *max7360, u8 reg, u8 val)
+{
+ return regmap_write(max7360->regmap, reg, val);
+}
+
+static inline int max7360_set_bits(struct max7360 *max7360, u8 reg,
+ unsigned int bit_mask)
+{
+ return regmap_update_bits(max7360->regmap, reg, bit_mask, bit_mask);
+}
+
+static inline int max7360_clr_bits(struct max7360 *max7360, u8 reg,
+ unsigned int bit_mask)
+{
+ return regmap_update_bits(max7360->regmap, reg, bit_mask, 0);
+}
+
+static inline int max7360_update(struct max7360 *max7360, u8 reg, u8 val,
+ unsigned int bit_mask)
+{
+ return regmap_update_bits(max7360->regmap, reg, bit_mask, val);
+}
+
+int max7360_request_pin(struct max7360 *max7360, u8 pin);
+void max7360_free_pin(struct max7360 *max7360, u8 pin);
+
+void max7360_take_catnap(struct max7360 *max7360);
+void max7360_fall_deepsleep(struct max7360 *max7360);
+
+int max7360_request_gpo_pin_count(struct max7360 *max7360, u8 count);
+int max7360_request_col_count(struct max7360 *max7360, u8 count);
+
+#endif
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] Add DT bindings documentation for the max7360 mfd driver
From: Valentin Sitdikov @ 2017-04-25 8:15 UTC (permalink / raw)
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Valentin Sitdikov, Andrei Dranitca
In-Reply-To: <20170425081557.13941-1-valentin_sitdikov-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Valentin Sitdikov <valentin_sitdikov-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Andrei Dranitca <Andrei_Dranitca-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/mfd/max7360.txt | 72 +++++++++++++++++++++++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max7360.txt
diff --git a/Documentation/devicetree/bindings/mfd/max7360.txt b/Documentation/devicetree/bindings/mfd/max7360.txt
new file mode 100644
index 0000000..359073a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max7360.txt
@@ -0,0 +1,72 @@
+* Maxim MAX7360 multi-function device
+
+The Maxim MAX7360 is a multifunction device which includes
+64 key switches, eight LED drivers/GPIOs, PWM intensity control,
+and rotary switch control.
+
+Required properties:
+- compatible: Should be the following: "maxim,max7360"
+- reg: Specifies the i2c slave address of the max7360 block. It can be 0x38, 0x3a, 0x3c or 0x3e IIUC.
+
+Optional properties:
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+ the interrupts from MAX7360 are routed to.
+- interrupt-names: might be "int-shared" or list of "inti" and "intk"
+- interrupt-controller: Identifies the device as an interrupt controller.
+- #interrupt-cells : Number of cells to encode an interrupt source, shall be 1.
+
+Examples:
+
+Without subnodes:
+ max7360@38 {
+ compatible = "maxim,max7360";
+ reg = <0x38>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "int-shared";
+ interrupt-controller;
+ #interrupt-cells = <0x1>;
+
+ };
+
+With subnodes:
+ max7360@38 {
+ compatible = "maxim,max7360";
+ reg = <0x38>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "int-shared";
+ interrupt-controller;
+ #interrupt-cells = <0x1>;
+
+ max7360_gpio: max7360_gpio@0 {
+ compatible = "maxim,max7360-gpio";
+ gpio-controller;
+ #gpio-cells = <0x2>;
+ interrupt-controller;
+ #interrupt-cells = <0x2>;
+ interrupts = <0>;
+ };
+
+ max7360_keypad {
+ compatible = "maxim,max7360-keypad";
+ maxim,debounce_reg = /bits/ 8 <0xef>;
+ maxim,ports_reg = /bits/ 8 <0xae>;
+ linux,keymap = < MATRIX_KEY(0, 0, KEY_F5)
+ MATRIX_KEY(1, 0, KEY_F4) >;
+ keypad,num-rows = <2>;
+ keypad,num-columns = <1>;
+ interrupts = <1>;
+ };
+
+ max7360_pwm: max7360_pwm {
+ compatible = "maxim,max7360-pwm";
+ #pwm-cells = <0x2>;
+ };
+
+ max7360_rotary_encoder {
+ compatible = "maxim,max7360-rotary";
+ interrupts = <2>;
+ };
+
+ };
--
2.9.3
--
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 0/2] Add max7360 mfd driver and DT documentation
From: Valentin Sitdikov @ 2017-04-25 8:15 UTC (permalink / raw)
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Valentin Sitdikov
This series add initial support of mfd core driver for max7360 chip
Andrei Dranitca (1):
mfd: max7360: Add mfd core device driver
Valentin Sitdikov (1):
Add DT bindings documentation for the max7360 mfd driver
Documentation/devicetree/bindings/mfd/max7360.txt | 72 ++++
drivers/mfd/Kconfig | 16 +
drivers/mfd/Makefile | 1 +
drivers/mfd/max7360.c | 393 ++++++++++++++++++++++
include/linux/mfd/max7360.h | 130 +++++++
5 files changed, 612 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max7360.txt
create mode 100644 drivers/mfd/max7360.c
create mode 100644 include/linux/mfd/max7360.h
--
2.9.3
--
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 1/5 v3] usb: host: add DT bindings for faraday fotg2
From: Linus Walleij @ 2017-04-25 8:12 UTC (permalink / raw)
To: Hans Ulli Kroll
Cc: openwrt-devel, devicetree@vger.kernel.org, Paulius Zaleckas,
Greg Kroah-Hartman, linux-usb@vger.kernel.org, Janos Laube,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <alpine.LNX.2.00.1704241846300.15211@T420s>
On Mon, Apr 24, 2017 at 6:53 PM, Hans Ulli Kroll
<ulli.kroll@googlemail.com> wrote:
> Got NAK'ed from Rob on some ealier round due missing "device mode" on this
> IP. I've blatantly overrided this to a host only driver.
>
> These are the needed changes in DT to support both modes
> Note the -dr at the end of fotg210, to reflect this in an dual role device
OK I understood the discussion such that the compatible should
simply be ""faraday,fotg210" as that is the name of the hardware
IP block. This is the name of the hardware name in the Faraday
page:
http://www.faraday-tech.com/html/Product/IPProduct/InterfaceIP/USB2_0.htm
Any other string implies how it is used, so that was what I understood
as the reason to reject it with the "-hcd" (host controller device) suffix.
> +- dr_mode : indicates the working mode for "fotg210-dr" compatible
> + controllers. Can be "host", "peripheral". Default to
> + "host" if not defined for backward compatibility.
This seems right, so it is part of the generic bindings, correct?
> usb@68000000 {
> - compatible = "cortina,gemini-usb", "faraday,fotg210";
> + compatible = "cortina,gemini-usb", "faraday,fotg210-dr";
But this would be wrong, because the compatible should only
indicate what kind of hardware it is, not how it is going to be used
(whether as host only, slave only or dual-role (OTG).
I hope I didn't get anything wrong here :/
Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
^ permalink raw reply
* Re: [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Geert Uytterhoeven @ 2017-04-25 8:09 UTC (permalink / raw)
To: Jiada Wang
Cc: Mark Rutland, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Rob Herring, linux-spi, Mark Brown,
Sascha Hauer, Fabio Estevam, Shawn Guo,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <58FF0127.7070703@mentor.com>
Hi Jiada,
On Tue, Apr 25, 2017 at 9:56 AM, Jiada Wang <jiada_wang@mentor.com> wrote:
> On 04/24/2017 06:10 AM, Geert Uytterhoeven wrote:
>> On Mon, Apr 24, 2017 at 2:48 PM, Jiada Wang<jiada_wang@mentor.com> wrote:
>>> On 04/24/2017 03:55 AM, Geert Uytterhoeven wrote:
>>>> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang<jiada_wang@mentor.com>
>>>> wrote:
>>>>> Our use case is to use spidev as an interface to communicate with
>>>>> external
>>>>> SPI master devices.
>>>>> meanwhile the SPI bus controller can also act as master device to send
>>>>> data
>>>>> to other
>>>>> SPI slave devices on the board.
>>>>
>>>> That sounds a bit hackish to me. SPI was never meant to be a
>>>> multi-master
>>>> bus.
>>>> While it can be done, you will need external synchronization (signals)
>>>> to
>>>> avoid conflicts between the SPI masters.
>>>
>>> It doesn't need to be a multi-master bus,
>>> for example A is master device for slave device B.
>>> while B has its own slave device C
>>> for each SPI connection A<=> B, and B<=> C, there is only one master
>>> device.
>>>
>>> and I think from use case point of view, it's very normal,
>>> one CPU upon receives command from external SPI master device,
>>> it writes data to its own slave device (EEPROM) connected to it.
>>
>> So "A<=> B" and "B<=> C" are two distinct SPI buses?
>> Or do they share some signals?
>>
>> Your comment seems to suggest otherwise:
>
> the use case of
> "A (master) <=> B (slave)", "B (master) <=> C(slave)", do share MISO and
> MOSI lines,
> but there is no SS line between A and C. so for each SPI slave device, there
> is only one
> master device.
Do you share CLK, too? Then you need a slave select from B to C.
If you use a separate clock, the slave select from B to C can be optional.
> so I think the question becomes whether the above mentioned hardware setup
> is valid or not.
It's a non-conventional SPI bus setup, but it can work, provided you have
some form of synchronization between A and B.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
* Re: [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Uwe Kleine-König @ 2017-04-25 8:07 UTC (permalink / raw)
To: Jiada Wang
Cc: Mark Rutland, devicetree@vger.kernel.org, Mark Brown,
linux-kernel@vger.kernel.org, linux-spi, Rob Herring,
Geert Uytterhoeven, Sascha Hauer, Fabio Estevam, Shawn Guo,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <58FF0127.7070703@mentor.com>
Hello Jiada,
On Tue, Apr 25, 2017 at 12:56:23AM -0700, Jiada Wang wrote:
> the use case of
> "A (master) <=> B (slave)", "B (master) <=> C(slave)", do share MISO and
> MOSI lines,
> but there is no SS line between A and C. so for each SPI slave device, there
> is only one
> master device.
So you need a mutex to make A not use the bus while B communicates to C.
Otherwise you have two drivers on MOSI (A and B) and MISO (B and C).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] PM / Domains: Fix DT example
From: Ulf Hansson @ 2017-04-25 8:01 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, Kevin Hilman, linaro-kernel,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Vincent Guittot, devicetree@vger.kernel.org
In-Reply-To: <533b52e0ea175bf6bb893370c7f8c0309aae235a.1493104411.git.viresh.kumar@linaro.org>
On 25 April 2017 at 09:18, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> The power-domain provider's #power-domain-cells field is set to 0 and
> yet the children is using an index to point the power domain. Fix it by
> removing the index field.
>
> Fixes: 70bb510e4279 ("dt/bindings / PM/Domains: Update binding for PM domain idle states")
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/power/power_domain.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 940707d095cc..14bd9e945ff6 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -81,7 +81,7 @@ domain provided by the 'parent' power controller.
> child: power-controller@12341000 {
> compatible = "foo,power-controller";
> reg = <0x12341000 0x1000>;
> - power-domains = <&parent 0>;
> + power-domains = <&parent>;
> #power-domain-cells = <0>;
> domain-idle-states = <&DOMAIN_PWR_DN>;
> };
> --
> 2.12.0.432.g71c3a4f4ba37
>
^ permalink raw reply
* Re: [PATCH v7 4/5] i2c: aspeed: added driver for Aspeed I2C
From: Brendan Higgins @ 2017-04-25 8:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Joel Stanley, Vladimir Zapolskiy,
Kachalov Anton, Cédric Le Goater, linux-i2c, devicetree,
Linux Kernel Mailing List, OpenBMC Maillist, Ryan Chen
In-Reply-To: <1493086864.25766.266.camel@kernel.crashing.org>
Adding Ryan to thread.
>> +static int __aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus,
>> + struct platform_device *pdev)
>> +{
>
> Minor nit ... I'm really not fan of those underscores.
>
> We use __ functions in some cases in the kernel for low level
> helpers, usually when it's a low level variant of an existing
> function or an "unlocked" variant, but I don't think generalizing
> it to pretty much everything in the driver is worthwhile here.
>
> If you want to be explicit about locking, I would suggest you
> use a comment in front of the function explaining if it
> expects to be called with the lock held.
>
> We tend to only do that when *both* functions exist and one is
> implemented in term of the other.
Okay, I guess that makes sense. Sorry, I thought the "unlocked"
variant might refer to a function that you have to pay close attention
to the context in which it is called; with as many functions as I have
that require the lock to be held, I would like there to be some way to
say the function is "unsafe," but I guess if there is no convention to
do that, then there is no convention to do that.
^ permalink raw reply
* Re: [PATCH v4 07/10] mfd: axp20x: add axp20x-regulator cell for AXP803
From: Lee Jones @ 2017-04-25 7:57 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Liam Girdwood, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170424160103.9447-8-icenowy-h8G6r0blFSE@public.gmane.org>
On Tue, 25 Apr 2017, Icenowy Zheng wrote:
> As axp20x-regulator now supports AXP803, add a cell for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> Changes in v4:
> - Added a trailing comma for new cell, for easier further cell addition.
> Changes in v3:
> - Make the new cell one-liner.
>
> drivers/mfd/axp20x.c | 3 ++-
> drivers/regulator/axp20x-regulator.c | 6 +++---
These 2 changes are orthogonal, thus there is no reason to send them
bundled into a single patch. Doing so complicates things greatly.
Please resubmit the two changes separately, so that they may be
absorbed by our respective subsystems.
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 1dc6235778eb..917b6ddc4f15 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
> .name = "axp20x-pek",
> .num_resources = ARRAY_SIZE(axp803_pek_resources),
> .resources = axp803_pek_resources,
> - }
> + },
> + { .name = "axp20x-regulator" },
> };
>
> static struct mfd_cell axp806_cells[] = {
> diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
> index 9356ec8a9a1f..e2608fe770b9 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
> @@ -311,13 +311,13 @@ static const struct regulator_desc axp803_regulators[] = {
> AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
> AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
> AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
> - AXP_DESC_IO(AXP803, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
> + AXP_DESC_IO(AXP803, LDO_IO0, "ldo-io0", "ips", 700, 3300, 100,
> AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
> AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
> - AXP_DESC_IO(AXP803, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
> + AXP_DESC_IO(AXP803, LDO_IO1, "ldo-io1", "ips", 700, 3300, 100,
> AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
> AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
> - AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc_ldo", "ips", 3000),
> + AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc-ldo", "ips", 3000),
> };
>
> static const struct regulator_linear_range axp806_dcdca_ranges[] = {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 RFC 0/5] *** SPI Slave mode support ***
From: Jiada Wang @ 2017-04-25 7:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Brown, Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer,
Fabio Estevam, linux-spi,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAMuHMdVQS494-BAc-W-XOOLK8Xow85n+Cgih0FG+t4QxCFxhMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert
On 04/24/2017 06:10 AM, Geert Uytterhoeven wrote:
> Hi Jiada,
>
> On Mon, Apr 24, 2017 at 2:48 PM, Jiada Wang<jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:
>> On 04/24/2017 03:55 AM, Geert Uytterhoeven wrote:
>>> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang<jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:
>>>> On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:
>>>>> On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown<broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>>>> On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org wrote:
>>>>>>> From: Jiada Wang<jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
>>>>>>>
>>>>>>> v1:
>>>>>>> add Slave mode support in SPI core
>>>>>>> spidev create slave device when SPI controller work in slave mode
>>>>>>> spi-imx support to work in slave mode
>>>>>> Adding Geert who also had a series doing this in progress that was
>>>>>> getting very near to being merged.
>>>>> Thank you!
>>>>>
>>>>> Actually my plan is to fix the last remaining issues and resubmit for
>>>>> v4.13.
>>>> I noticed your patch set for SPI slave support,
>>>> (I am sure you can find out some of the change
>>>> in this patch set is based on your work).
>>>> we have similar requirement to add slave mode support to ecspi IP on imx6
>>>> Soc.
>>>>
>>>> Our use case is to use spidev as an interface to communicate with
>>>> external
>>>> SPI master devices.
>>>> meanwhile the SPI bus controller can also act as master device to send
>>>> data
>>>> to other
>>>> SPI slave devices on the board.
>>> That sounds a bit hackish to me. SPI was never meant to be a multi-master
>>> bus.
>>> While it can be done, you will need external synchronization (signals) to
>>> avoid conflicts between the SPI masters.
>> It doesn't need to be a multi-master bus,
>> for example A is master device for slave device B.
>> while B has its own slave device C
>> for each SPI connection A<=> B, and B<=> C, there is only one master
>> device.
>>
>> and I think from use case point of view, it's very normal,
>> one CPU upon receives command from external SPI master device,
>> it writes data to its own slave device (EEPROM) connected to it.
> So "A<=> B" and "B<=> C" are two distinct SPI buses?
> Or do they share some signals?
>
> Your comment seems to suggest otherwise:
the use case of
"A (master) <=> B (slave)", "B (master) <=> C(slave)", do share MISO and
MOSI lines,
but there is no SS line between A and C. so for each SPI slave device,
there is only one
master device.
so I think the question becomes whether the above mentioned hardware
setup is valid or not.
Thanks,
Jiada
>>>> I found in your implementation, SPI bus controller is limited to either work in master mode or
>>>> slave mode, is there any reasoning to not configure SPI mode based on SPI devices use case?
> If they are distinct, it should work. Then B has two SPI controllers: one slave
> controller controlled by A, and one master controller to control C.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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 linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] PM / Domains: Fix DT example
From: Viresh Kumar @ 2017-04-25 7:18 UTC (permalink / raw)
To: Rafael Wysocki, Kevin Hilman, Ulf Hansson
Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
Viresh Kumar, devicetree-u79uwXL29TY76Z2rM5mHXA
The power-domain provider's #power-domain-cells field is set to 0 and
yet the children is using an index to point the power domain. Fix it by
removing the index field.
Fixes: 70bb510e4279 ("dt/bindings / PM/Domains: Update binding for PM domain idle states")
Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/power/power_domain.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 940707d095cc..14bd9e945ff6 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -81,7 +81,7 @@ domain provided by the 'parent' power controller.
child: power-controller@12341000 {
compatible = "foo,power-controller";
reg = <0x12341000 0x1000>;
- power-domains = <&parent 0>;
+ power-domains = <&parent>;
#power-domain-cells = <0>;
domain-idle-states = <&DOMAIN_PWR_DN>;
};
--
2.12.0.432.g71c3a4f4ba37
--
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: [PATCHv2 2/3] ARM: drm: Intel FPGA VIP Frame Buffer II drm driver
From: Jani Nikula @ 2017-04-25 7:17 UTC (permalink / raw)
To: daniel.vetter-ral2JQCrhuEAvxtiuMwx3w,
dinguyen-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
tien.hock.loh-ral2JQCrhuEAvxtiuMwx3w, Ong-CC+yJ3UmIYqDUpFQwHEjaQ,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <1493086006-4392-3-git-send-email-hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Tue, 25 Apr 2017, hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> +++ b/drivers/gpu/drm/ivip/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# Makefile for the drm device driver. This driver provides support for the
> +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> +
> +ccflags-y := -Iinclude/drm
Just a drive-by observation, there are patches on the list removing such
ccflags from existing drivers. You shouldn't need this. Just make sure
all your #includes begin with <drm/.
BR,
Jani.
> +
> +obj-$(CONFIG_DRM_IVIP) += ivip.o
> +ivip-objs := intel_vip_of.o intel_vip_core.o \
> +intel_vip_conn.o
--
Jani Nikula, Intel Open Source Technology Center
--
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 2/4] gpio - Add EXAR XRA1403 SPI GPIO expander driver
From: Geert Uytterhoeven @ 2017-04-25 7:15 UTC (permalink / raw)
To: zoobab
Cc: Linus Walleij, Nandor Han, Greg KH, David S. Miller,
Mauro Carvalho Chehab, Daniel Vetter, Alexandre Courbot,
Rob Herring, Mark Rutland, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Semi Malinen
In-Reply-To: <CANjd3ndZkVi5OA0eqDewrpqVLQpT11QbVOA98F=ghMhcwPu2hQ@mail.gmail.com>
Hi Benjamin,
On Tue, Apr 25, 2017 at 9:07 AM, Benjamin Henrion <zoobab@gmail.com> wrote:
> On Mon, Apr 24, 2017 at 3:47 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Thu, Apr 13, 2017 at 12:27 PM, Nandor Han <nandor.han@ge.com> wrote:
>>
>>> This is a simple driver that provides a /sys/class/gpio
>>> interface for controlling and configuring the GPIO lines.
>>> It does not provide support for chip select or interrupts.
>>>
>>> Signed-off-by: Nandor Han <nandor.han@ge.com>
>>> Signed-off-by: Semi Malinen <semi.malinen@ge.com>
>>
>> I almost want to make the driver depend on !GPIO_SYSFS because
>> of this commit message.
>>
>> DO NOT USE OR ENCOURAGE THE USE OF THE GPIO SYSFS
>> INTERFACE.
>>
>> Use the character device.
>
> I doubt you will be able to convince the majority of people toggling
> GPIOs via a simple shell script to switch to write a complex C
> program. Not to mention cross compilation and the libraries
> dependencies here.
>
> Is there some good cli tools to access the new char device? If they
> are shipped with most distros, that would reduce the pain.
https://github.com/brgl/libgpiod
A bit early to expect it to be shipped with all distros, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos: Remove the te-gpios property in the TM2 boards
From: Inki Dae @ 2017-04-25 7:12 UTC (permalink / raw)
To: Hoegeun Kwon, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, kgene-DgEjT+Ai2ygdnm+yROfE0A,
krzk-DgEjT+Ai2ygdnm+yROfE0A
Cc: javier-JPH+aEBZ4P+UEJcrhfAQsw, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
a.hajda-Sze3O3UU22JBDgjK7y7TUQ
In-Reply-To: <1493085261-3488-1-git-send-email-hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017년 04월 25일 10:54에 Hoegeun Kwon 이(가) 쓴 글:
> The decon uses HW-TRIGGER, so TE interrupt is not necessary.
> Therefore, remove the te-gpios property in the TM2 dts.
>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 3ff9527..23191eb 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -60,7 +60,6 @@
> vci-supply = <&ldo28_reg>;
> reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> - te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
Reviewed-by: Inki Dae <inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Thanks,
Inki Dae
> };
> };
>
>
--
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 2/4] gpio - Add EXAR XRA1403 SPI GPIO expander driver
From: Benjamin Henrion @ 2017-04-25 7:07 UTC (permalink / raw)
To: Linus Walleij
Cc: Nandor Han, Greg KH, David S. Miller, Geert Uytterhoeven,
Mauro Carvalho Chehab, Daniel Vetter, Alexandre Courbot,
Rob Herring, Mark Rutland, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Semi Malinen
In-Reply-To: <CACRpkdZHMWH2W-i4MGZ7NKzPHUURRmC-5YwiK7cVLCHKDsb7sw@mail.gmail.com>
On Mon, Apr 24, 2017 at 3:47 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Apr 13, 2017 at 12:27 PM, Nandor Han <nandor.han@ge.com> wrote:
>
>> This is a simple driver that provides a /sys/class/gpio
>> interface for controlling and configuring the GPIO lines.
>> It does not provide support for chip select or interrupts.
>>
>> Signed-off-by: Nandor Han <nandor.han@ge.com>
>> Signed-off-by: Semi Malinen <semi.malinen@ge.com>
>
> I almost want to make the driver depend on !GPIO_SYSFS because
> of this commit message.
>
> DO NOT USE OR ENCOURAGE THE USE OF THE GPIO SYSFS
> INTERFACE.
>
> Use the character device.
I doubt you will be able to convince the majority of people toggling
GPIOs via a simple shell script to switch to write a complex C
program. Not to mention cross compilation and the libraries
dependencies here.
Is there some good cli tools to access the new char device? If they
are shipped with most distros, that would reduce the pain.
Best,
--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."
^ permalink raw reply
* Re: [PATCH 11/13] phy: Add an USB PHY driver for the Lantiq SoCs using the RCU module
From: Hauke Mehrtens @ 2017-04-25 7:06 UTC (permalink / raw)
To: Rob Herring
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg,
john-Pj+rj9U5foFAfugRpC6u6w, linux-spi-u79uwXL29TY76Z2rM5mHXA,
hauke.mehrtens-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170420153606.fdhedc7ovvhc66qd@rob-hp-laptop>
On 04/20/2017 05:36 PM, Rob Herring wrote:
> On Mon, Apr 17, 2017 at 09:29:40PM +0200, Hauke Mehrtens wrote:
>> From: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>
>> This driver starts the DWC2 core(s) built into the XWAY SoCs and provides
>> the PHY interfaces for each core. The phy instances can be passed to the
>> dwc2 driver, which already supports the generic phy interface.
>>
>> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
>> ---
>> .../bindings/phy/phy-lantiq-rcu-usb2.txt | 59 ++++
>> arch/mips/lantiq/xway/reset.c | 43 ---
>> arch/mips/lantiq/xway/sysctrl.c | 24 +-
>> drivers/phy/Kconfig | 8 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-lantiq-rcu-usb2.c | 325 +++++++++++++++++++++
>> 6 files changed, 405 insertions(+), 55 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> create mode 100644 drivers/phy/phy-lantiq-rcu-usb2.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt b/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> new file mode 100644
>> index 000000000000..0ec9f790b6e0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> @@ -0,0 +1,59 @@
>> +Lantiq XWAY SoC RCU USB 1.1/2.0 PHY binding
>> +===========================================
>> +
>> +This binding describes the USB PHY hardware provided by the RCU module on the
>> +Lantiq XWAY SoCs.
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties (controller (parent) node):
>> +- compatible : Should be one of
>> + "lantiq,ase-rcu-usb2-phy"
>> + "lantiq,danube-rcu-usb2-phy"
>> + "lantiq,xrx100-rcu-usb2-phy"
>> + "lantiq,xrx200-rcu-usb2-phy"
>> + "lantiq,xrx300-rcu-usb2-phy"
>
> The first x in xrx seems to be a wildcard. Don't use wildcards in
> compatible strings.
Yes that is correct, I will replace it in the newly introduced
compatible strings with the full names without wild cards.
>
>> +- lantiq,rcu-syscon : A phandle to the RCU module and the offsets to the
>> + USB PHY configuration and USB MAC registers.
>
> Same comment as gphy.
>
>> +- address-cells : should be 1
>> +- size-cells : should be 0
>> +- phy-cells : from the generic PHY bindings, must be 1
>
> Missing the '#'
>
>> +
>> +Optional properties (controller (parent) node):
>> +- vbus-gpio : References a GPIO which enables VBUS all given USB
>> + ports.
>
> -gpios is preferred form.
>
>> +
>> +Required nodes : A sub-node is required for each USB PHY port.
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties (port (child) node):
>
> Where's the sub nodes in the example?
Sorry, this was from an older version, I will update this.
>
>> +- reg : The ID of the USB port, usually 0 or 1.
>> +- clocks : References to the (PMU) "ctrl" and "phy" clk gates.
>> +- clock-names : Must be one of the following:
>> + "ctrl"
>> + "phy"
>> +- resets : References to the RCU USB configuration reset bits.
>> +- reset-names : Must be one of the following:
>> + "analog-config" (optional)
>> + "statemachine-soft" (optional)
>> +
>> +Optional properties (port (child) node):
>> +- vbus-gpio : References a GPIO which enables VBUS for the USB port.
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Example for the USB PHYs on an xRX200 SoC:
>> + usb_phys0: rcu-usb2-phy@0 {
>
> usb-phy@...
>
>> + compatible = "lantiq,xrx200-rcu-usb2-phy";
>
> Extra spaces.
>
>> + reg = <0>;
>> +
>> + lantiq,rcu-syscon = <&rcu0 0x18 0x38>;
>> + clocks = <&pmu PMU_GATE_USB0_CTRL>,
>> + <&pmu PMU_GATE_USB0_PHY>;
>> + clock-names = "ctrl", "phy";
>> + vbus-gpios = <&gpio 32 GPIO_ACTIVE_HIGH>;
>> + resets = <&rcu_reset1 4>, <&rcu_reset0 4>;
>> + reset-names = "phy", "ctrl";
>> + #phy-cells = <0>;
>> + };
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 09/13] MIPS: lantiq: Add a GPHY driver which uses the RCU syscon-mfd
From: Hauke Mehrtens @ 2017-04-25 7:05 UTC (permalink / raw)
To: Rob Herring
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg,
john-Pj+rj9U5foFAfugRpC6u6w, linux-spi-u79uwXL29TY76Z2rM5mHXA,
hauke.mehrtens-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170420152754.3tkjxjvoiuatbvpo@rob-hp-laptop>
On 04/20/2017 05:27 PM, Rob Herring wrote:
> On Mon, Apr 17, 2017 at 09:29:38PM +0200, Hauke Mehrtens wrote:
>> From: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>
>> Compared to the old xrx200_phy_fw driver the new version has multiple
>> enhancements. The name of the firmware files does not have to be added
>> to all .dts files anymore - one now configures the GPHY mode (FE or GE)
>> instead. Each GPHY can now also boot separate firmware (thus mixing of
>> GE and FE GPHYs is now possible).
>> The new implementation is based on the RCU syscon-mfd and uses the
>> reeset_controller framework instead of raw RCU register reads/writes.
>>
>> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
>> ---
>> .../devicetree/bindings/mips/lantiq/rcu-gphy.txt | 54 +++++
>> arch/mips/lantiq/xway/sysctrl.c | 4 +-
>> drivers/soc/lantiq/Makefile | 1 +
>> drivers/soc/lantiq/gphy.c | 242 +++++++++++++++++++++
>> include/dt-bindings/mips/lantiq_rcu_gphy.h | 15 ++
>> 5 files changed, 314 insertions(+), 2 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
>> create mode 100644 drivers/soc/lantiq/gphy.c
>> create mode 100644 include/dt-bindings/mips/lantiq_rcu_gphy.h
>>
>> diff --git a/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt b/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
>> new file mode 100644
>> index 000000000000..d525c7ce9f0b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
>> @@ -0,0 +1,54 @@
>> +Lantiq XWAY SoC GPHY binding
>> +============================
>> +
>> +This binding describes a software-defined ethernet PHY, provided by the RCU
>> +module on newer Lantiq XWAY SoCs (xRX200 and newer).
>> +This depends on binary firmware blobs which must be provided by userspace.
>
> Where the blobs come from is not relevant.
>
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties (controller (parent) node):
>> +- compatible : Should be one of
>> + "lantiq,xrx200a1x-rcu-gphy"
>> + "lantiq,xrx200a2x-rcu-gphy"
>> + "lantiq,xrx300-rcu-gphy"
>> + "lantiq,xrx330-rcu-gphy"
>> +- lantiq,rcu-syscon : A phandle and offset to the GPHY address registers in
>> + the RCU
>> +- resets : Must reference the RCU GPHY reset bit
>> +- reset-names : One entry, value must be "gphy" or optional "gphy2"
>> +
>> +Optional properties (port (child) node):
>> +- lantiq,gphy-mode : GPHY_MODE_GE (default) or GPHY_MODE_FE as defined in
>> + <dt-bindings/mips/lantiq_xway_gphy.h>
>> +- clocks : A reference to the (PMU) GPHY clock gate
>> +- clock-names : If clocks is given then this must be "gphy"
>
> Kind of pointless to have a name for a single clock.
The documentation misses the 2. clock. ;-) Will add it.
>
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Example for the GPHys on the xRX200 SoCs:
>> +
>> +#include <dt-bindings/mips/lantiq_rcu_gphy.h>
>> + gphy0: rcu_gphy@0 {
>
> Use generic node names: phy@...
I will change this
>
>> + compatible = "lantiq,xrx200a2x-rcu-gphy";
>> + reg = <0>;
>> +
>> + lantiq,rcu-syscon = <&rcu0 0x20>;
>
> Could the phy just be a child of the rcu? Then you don't need a phandle
> here and 0x20 becomes the reg address.
The RCU is a register block which does many things. This register is
specific to this ghpy, but there are some register in the RCU block
which are shared between multiple drivers. Can I support both, provide
some parts of this block as syscon and some as direct register blocks?
>
>> + resets = <&rcu_reset0 31>, <&rcu_reset1 7>;
>> + reset-names = "gphy", "gphy2";
>> + lantiq,gphy-mode = <GPHY_MODE_GE>;
>> + clocks = <&pmu0 XRX200_PMU_GATE_GPHY>;
>> + clock-names = "gphy";
>> + };
>> +
>> + gphy1: rcu_gphy@1 {
>> + compatible = "lantiq,xrx200a2x-rcu-gphy";
>> + reg = <0>;
>> +
>> + lantiq,rcu-syscon = <&rcu0 0x68>;
>> + resets = <&rcu_reset0 29>, <&rcu_reset1 6>;
>> + reset-names = "gphy", "gphy2";
>> + lantiq,gphy-mode = <GPHY_MODE_FE>;
>> + clocks = <&pmu0 XRX200_PMU_GATE_GPHY>;
>> + clock-names = "gphy";
>> + };
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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 08/13] reset: Add a reset controller driver for the Lantiq XWAY based SoCs
From: Hauke Mehrtens @ 2017-04-25 7:00 UTC (permalink / raw)
To: Rob Herring
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg,
john-Pj+rj9U5foFAfugRpC6u6w, linux-spi-u79uwXL29TY76Z2rM5mHXA,
hauke.mehrtens-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170420145405.7s3iapxggr5575d2@rob-hp-laptop>
On 04/20/2017 04:54 PM, Rob Herring wrote:
> On Mon, Apr 17, 2017 at 09:29:37PM +0200, Hauke Mehrtens wrote:
>> From: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>
>> The reset controllers (on xRX200 and newer SoCs have two of them) are
>> provided by the RCU module. This was initially implemented as a simple
>> reset controller. However, the RCU module provides more functionality
>> (ethernet GPHYs, USB PHY, etc.), which makes it a MFD device.
>> The old reset controller driver implementation from
>> arch/mips/lantiq/xway/reset.c did not honor this fact.
>>
>> For some devices the request and the status bits are different.
>>
>> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
>> ---
>> .../devicetree/bindings/reset/lantiq,rcu-reset.txt | 43 ++++
>> arch/mips/lantiq/xway/reset.c | 68 ------
>> drivers/reset/Kconfig | 6 +
>> drivers/reset/Makefile | 1 +
>> drivers/reset/reset-lantiq-rcu.c | 231 +++++++++++++++++++++
>> 5 files changed, 281 insertions(+), 68 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt
>> create mode 100644 drivers/reset/reset-lantiq-rcu.c
>>
>> diff --git a/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt b/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt
>> new file mode 100644
>> index 000000000000..7f097d16bbb7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt
>> @@ -0,0 +1,43 @@
>> +Lantiq XWAY SoC RCU reset controller binding
>> +============================================
>> +
>> +This binding describes a reset-controller found on the RCU module on Lantiq
>> +XWAY SoCs.
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties (controller (parent) node):
>> +- compatible : Should be "lantiq,rcu-reset"
>> +- lantiq,rcu-syscon : A phandle to the RCU syscon, the reset register
>> + offset and the status register offset.
>> +- #reset-cells : Specifies the number of cells needed to encode the
>> + reset line, should be 1.
>> +
>> +Optional properties:
>> +- reset-status : The request status bit. For some bits the request bit
>> + and the status bit are different. This is depending
>> + on the SoC. If the reset-status bit does not match
>> + the reset-request bit, put the reset number into the
>> + reset-request property and the status bit at the same
>> + index into the reset-status property. If no
>> + reset-request bit is given here, the driver assume
>> + status and request bit are the same.
>> +- reset-request : The reset request bit, to map it to the reset-status
>> + bit.
>
> These should either be implied by SoC specific compatible or be made
> part of the reset cells. In the latter case, you still need the SoC
> specific compatible.
Currently the reset framework only supports a single reset cell to my
knowledge, but I haven't looked into the details, I could extend it to
make it support two.
The SoC which needs this has two reset control register sets and the
bits are specific for each register set. Would a specific compatible
string for each register set ok?
>
>> +-------------------------------------------------------------------------------
>> +Example for the reset-controllers on the xRX200 SoCs:
>> + rcu_reset0: rcu_reset {
>> + compatible = "lantiq,rcu-reset";
>> + lantiq,rcu-syscon = <&rcu0 0x10 0x14>;
>> + #reset-cells = <1>;
>> + reset-request = <31>, <29>, <21>, <19>, <16>, <12>;
>> + reset-status = <30>, <28>, <16>, <25>, <5>, <24>;
>> + };
>> +
>> + rcu_reset1: rcu_reset {
>> + compatible = "lantiq,rcu-reset";
>
> These 2 blocks are identical? Given different registers sizes, I'd say
> not. So they should have different compatible strings.
I will remove the second one.
>
>> + lantiq,rcu-syscon = <&rcu0 0x48 0x24>;
>> + #reset-cells = <1>;
>> + };
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 06/13] MIPS: lantiq: Convert the xbar driver to a platform_driver
From: Hauke Mehrtens @ 2017-04-25 6:56 UTC (permalink / raw)
To: Rob Herring
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg,
john-Pj+rj9U5foFAfugRpC6u6w, linux-spi-u79uwXL29TY76Z2rM5mHXA,
hauke.mehrtens-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170420144848.hwvtrhnwxcsxyv7x@rob-hp-laptop>
On 04/20/2017 04:48 PM, Rob Herring wrote:
> On Mon, Apr 17, 2017 at 09:29:35PM +0200, Hauke Mehrtens wrote:
>> From: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>
>> This allows using the xbar driver on ARX300 based SoCs which require the
>> same xbar setup as the xRX200 chipsets because the xbar driver
>> initialization is not guarded by an xRX200 specific
>> of_machine_is_compatible condition anymore. Additionally the new driver
>> takes a syscon phandle to configure the XBAR endianness bits in RCU
>> (before this was done in arch/mips/lantiq/xway/reset.c and also
>> guarded by an xRX200 specific if-statement).
>>
>> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
>> ---
>> .../devicetree/bindings/mips/lantiq/xbar.txt | 22 +++++
>> MAINTAINERS | 1 +
>> arch/mips/lantiq/xway/reset.c | 4 -
>> arch/mips/lantiq/xway/sysctrl.c | 41 ---------
>> drivers/soc/Makefile | 1 +
>> drivers/soc/lantiq/Makefile | 1 +
>> drivers/soc/lantiq/xbar.c | 100 +++++++++++++++++++++
>> 7 files changed, 125 insertions(+), 45 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mips/lantiq/xbar.txt
>> create mode 100644 drivers/soc/lantiq/Makefile
>> create mode 100644 drivers/soc/lantiq/xbar.c
>>
>> diff --git a/Documentation/devicetree/bindings/mips/lantiq/xbar.txt b/Documentation/devicetree/bindings/mips/lantiq/xbar.txt
>> new file mode 100644
>> index 000000000000..86e53ff3b0d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mips/lantiq/xbar.txt
>> @@ -0,0 +1,22 @@
>> +Lantiq XWAY SoC XBAR binding
>> +============================
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties:
>> +- compatible : Should be "lantiq,xbar-xway"
>
> This compatible is already in use so it is fine, but you should also
> have per SoC compatible strings.
I will add a new SoC specific one.
What does per SoC device tree mean? Does it mean for the same silicon,
for the same silicon revision, for the same fusing of a silicon or for
the same marketing name?
I would like to make it per silicon or per silicon revision for the IP
cores which I know are different.
Hauke
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/3] mtd: nand: Cleanup/rework the atmel_nand driver
From: Boris Brezillon @ 2017-04-25 6:53 UTC (permalink / raw)
To: Brian Norris
Cc: Richard Weinberger, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Nicolas Ferre, Alexandre Belloni, Haavard Skinnemoen,
Hans-Christian Egtvedt, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Wenyou Yang, Josh Wu, David Woodhouse, Marek Vasut,
Cyrille Pitchen,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA, Masahiro Yamada
In-Reply-To: <20170425010930.GA120971-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Mon, 24 Apr 2017 18:09:30 -0700
Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Mar 16, 2017 at 09:02:40AM +0100, Boris Brezillon wrote:
>
> > diff --git a/drivers/mtd/nand/atmel/nand-controller.c b/drivers/mtd/nand/atmel/nand-controller.c
> > new file mode 100644
> > index 000000000000..f71b9e5d7d9d
> > --- /dev/null
> > +++ b/drivers/mtd/nand/atmel/nand-controller.c
> > @@ -0,0 +1,2198 @@
> [...]
>
> > +static int
> > +atmel_hsmc_nand_controller_legacy_init(struct atmel_hsmc_nand_controller *nc)
> > +{
> > + struct regmap_config regmap_conf = {
> > + .reg_bits = 32,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > + .val_bits = 32,
>
> You assigned val_bits twice. Is that just a harmless mistake, or did you
> mean to set something else?
Nope, I didn't mean to set another field to 32. I'll just apply the fix
you provided.
Thanks,
Boris
--
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 11/13] phy: Add an USB PHY driver for the Lantiq SoCs using the RCU module
From: Hauke Mehrtens @ 2017-04-25 6:51 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, john-Pj+rj9U5foFAfugRpC6u6w,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
hauke.mehrtens-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <CAFBinCAB=vaDpzCoMFX8w9j0R04i6Zr4mbjDtteKsQ_LkKAaLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 04/17/2017 11:23 PM, Martin Blumenstingl wrote:
> On Mon, Apr 17, 2017 at 9:29 PM, Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org> wrote:
>> From: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>
>> This driver starts the DWC2 core(s) built into the XWAY SoCs and provides
>> the PHY interfaces for each core. The phy instances can be passed to the
>> dwc2 driver, which already supports the generic phy interface.
>>
>> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
> you should probably send this patch to the PHY maintainer as well
> (Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>)
>
>> ---
>> .../bindings/phy/phy-lantiq-rcu-usb2.txt | 59 ++++
>> arch/mips/lantiq/xway/reset.c | 43 ---
>> arch/mips/lantiq/xway/sysctrl.c | 24 +-
>> drivers/phy/Kconfig | 8 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-lantiq-rcu-usb2.c | 325 +++++++++++++++++++++
>> 6 files changed, 405 insertions(+), 55 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> create mode 100644 drivers/phy/phy-lantiq-rcu-usb2.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt b/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> new file mode 100644
>> index 000000000000..0ec9f790b6e0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> @@ -0,0 +1,59 @@
>> +Lantiq XWAY SoC RCU USB 1.1/2.0 PHY binding
>> +===========================================
>> +
>> +This binding describes the USB PHY hardware provided by the RCU module on the
>> +Lantiq XWAY SoCs.
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties (controller (parent) node):
>> +- compatible : Should be one of
>> + "lantiq,ase-rcu-usb2-phy"
>> + "lantiq,danube-rcu-usb2-phy"
>> + "lantiq,xrx100-rcu-usb2-phy"
>> + "lantiq,xrx200-rcu-usb2-phy"
>> + "lantiq,xrx300-rcu-usb2-phy"
>> +- lantiq,rcu-syscon : A phandle to the RCU module and the offsets to the
>> + USB PHY configuration and USB MAC registers.
>> +- address-cells : should be 1
>> +- size-cells : should be 0
>> +- phy-cells : from the generic PHY bindings, must be 1
>> +
>> +Optional properties (controller (parent) node):
>> +- vbus-gpio : References a GPIO which enables VBUS all given USB
>> + ports.
> the PHY framework already handles this if you wrap the GPIO in a
> "regulator-fixed" node, see [0] how to define a fixed regulator with a
> GPIO (the regulator in this example has two states: off = 0V and on =
> 5V, probably exactly what you need) and [1] how to pass it to the PHY
> (phy-core.c handles this already, no driver specific code needed)
Thanksy, I will change the code and use a regulator.
......
>> diff --git a/arch/mips/lantiq/xway/reset.c b/arch/mips/lantiq/xway/reset.c
>> index 3f30fb81a50f..5aec1f54275b 100644
>> --- a/arch/mips/lantiq/xway/reset.c
>> +++ b/arch/mips/lantiq/xway/reset.c
> could these arch/mips/lantiq/xway/reset.c changes to into PATCH #3 as well?
I do not get this.
......
> [0] https://github.com/torvalds/linux/blob/2fbbc4bf69f293df317559a267f4120f290b8fc4/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi#L67
> [1] https://github.com/torvalds/linux/blob/2fbbc4bf69f293df317559a267f4120f290b8fc4/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi#L133
>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 2/2] clk: rockchip: fix the incorrect ids
From: Eddie Cai @ 2017-04-25 6:41 UTC (permalink / raw)
To: robh+dt, mark.rutland, heiko, zhengxing, mturquette, sboyd
Cc: devicetree, linux-kernel, linux-clk, linux-arm-kernel,
linux-rockchip, Eddie Cai
In-Reply-To: <1493102470-22965-1-git-send-email-eddie.cai.linux@gmail.com>
the ids of clk_testout1 and clk_testout2 is incorrect now. let's correct it
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
drivers/clk/rockchip/clk-rk3399.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c
index 73121b14..f3656ba 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -1066,13 +1066,13 @@ enum rk3399_pmu_plls {
/* cif_testout */
MUX(0, "clk_testout1_pll_src", mux_pll_src_cpll_gpll_npll_p, 0,
RK3399_CLKSEL_CON(38), 6, 2, MFLAGS),
- COMPOSITE(0, "clk_testout1", mux_clk_testout1_p, 0,
+ COMPOSITE(SCLK_TESTCLKOUT1, "clk_testout1", mux_clk_testout1_p, 0,
RK3399_CLKSEL_CON(38), 5, 1, MFLAGS, 0, 5, DFLAGS,
RK3399_CLKGATE_CON(13), 14, GFLAGS),
MUX(0, "clk_testout2_pll_src", mux_pll_src_cpll_gpll_npll_p, 0,
RK3399_CLKSEL_CON(38), 14, 2, MFLAGS),
- COMPOSITE(0, "clk_testout2", mux_clk_testout2_p, 0,
+ COMPOSITE(SCLK_TESTCLKOUT2, "clk_testout2", mux_clk_testout2_p, 0,
RK3399_CLKSEL_CON(38), 13, 1, MFLAGS, 8, 5, DFLAGS,
RK3399_CLKGATE_CON(13), 15, GFLAGS),
--
1.9.1
^ permalink raw reply related
* [PATCH V2 1/2] clk: rockchip: add ids for camera
From: Eddie Cai @ 2017-04-25 6:41 UTC (permalink / raw)
To: robh+dt, mark.rutland, heiko, zhengxing, mturquette, sboyd
Cc: devicetree, linux-kernel, linux-clk, linux-arm-kernel,
linux-rockchip, Eddie Cai
In-Reply-To: <1493102470-22965-1-git-send-email-eddie.cai.linux@gmail.com>
we use SCLK_TESTCLKOUT1 and SCLK_TESTCLKOUT2 for camera, so add those ids.
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
include/dt-bindings/clock/rk3399-cru.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h
index 220a60f..22cb1df 100644
--- a/include/dt-bindings/clock/rk3399-cru.h
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -132,6 +132,8 @@
#define SCLK_RMII_SRC 166
#define SCLK_PCIEPHY_REF100M 167
#define SCLK_DDRC 168
+#define SCLK_TESTCLKOUT1 169
+#define SCLK_TESTCLKOUT2 170
#define DCLK_VOP0 180
#define DCLK_VOP1 181
--
1.9.1
^ permalink raw reply related
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