* Re: [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Thomas Petazzoni @ 2016-11-10 8:22 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Andrew Lunn, Jason Cooper, devicetree, Rob Herring,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20161110001000.10619-5-gregory.clement@free-electrons.com>
Hello,
On Thu, 10 Nov 2016 01:09:50 +0100, Gregory CLEMENT wrote:
> - bootrom {
> + bootrom@0 {
> compatible = "marvell,bootrom";
> reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
I am still not sure whether this "0" unit address is correct compared
to the reg property being passed.
A good example of why I'm worried is the sa-sram case:
+ crypto_sram0: sa-sram0@0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
+ crypto_sram1: sa-sram1@0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
The node names should be just "sram" without a number. Indeed for UARTs
for example, you use uart@XYZ, uart@ABC and not uart0@XYZ and
uart1@ABC. But then, if you do that, with your scheme, you end up with
both nodes named sa-sram@0.
Which clearly shows that the way you set this unit-address is not
correct: those two devices are mapped at completely different
locations, but you end up with an identical unit address.
I have no idea what is the rule for setting the unit address in this
case, but I'm pretty sure the rule you've chosen is not good.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
From: Laurent Pinchart @ 2016-11-10 8:18 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: robh+dt, mark.rutland, mchehab, hverkuil, sakari.ailus, crope,
chris.paterson2, geert+renesas, linux-media, devicetree,
linux-renesas-soc
In-Reply-To: <1478706284-59134-5-git-send-email-ramesh.shanmugasundaram@bp.renesas.com>
Hi Ramesh,
Thank you for the patch.
On Wednesday 09 Nov 2016 15:44:43 Ramesh Shanmugasundaram wrote:
> This patch adds documentation for the three new SDR formats
>
> V4L2_SDR_FMT_SCU16BE
> V4L2_SDR_FMT_SCU18BE
> V4L2_SDR_FMT_SCU20BE
>
> Signed-off-by: Ramesh Shanmugasundaram
> <ramesh.shanmugasundaram@bp.renesas.com>
> ---
> .../media/uapi/v4l/pixfmt-sdr-scu16be.rst | 80 ++++++++++++++++++
> .../media/uapi/v4l/pixfmt-sdr-scu18be.rst | 80 ++++++++++++++++++
> .../media/uapi/v4l/pixfmt-sdr-scu20be.rst | 80 ++++++++++++++++++
> Documentation/media/uapi/v4l/sdr-formats.rst | 3 +
> 4 files changed, 243 insertions(+)
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-scu18be.rst
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-scu20be.rst
>
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst new file mode 100644
> index 0000000..7525378
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst
> @@ -0,0 +1,80 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-SDR-FMT-SCU16BE:
> +
> +******************************
> +V4L2_SDR_FMT_SCU16BE ('SC16')
> +******************************
> +
> +Sliced complex unsigned 16-bit big endian IQ sample
> +
> +Description
> +===========
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are represented as a 16 bit unsigned big endian number stored in
> +32 bit space. The remaining unused bits within the 32 bit space will be
> +padded with 0. I value starts first and Q value starts at an offset
> +equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
> +the 16 bits, bit 15:2 (14 bit) is data and bit 1:0 (2 bit) can be any
> +value.
I've pinged Antti and Hans regarding single buffer vs. multiplanar, let's try
to reach an agreement there.
> +
> +**Byte Order.**
> +Each cell is one byte.
> +
> +.. flat-table::
> + :header-rows: 1
> + :stub-columns: 0
> +
> + * - Offset:
> +
In the meantime, you can remove all the blank lines between table rows :-)
> + - Byte B0
> +
> + - Byte B1
> +
> + - Byte B2
> +
> + - Byte B3
[snip]
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/2] backlight: arcxcnn: add support for ArticSand devices
From: Lee Jones @ 2016-11-10 8:14 UTC (permalink / raw)
To: Olimpiu Dejeu
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20161109155307.GH13127@dell>
On Wed, 09 Nov 2016, Lee Jones wrote:
> Jingoo?
Ah, it looks like you used the wrong address.
I should have been: jingoohan1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
I'll CC him from here.
> On Wed, 26 Oct 2016, Olimpiu Dejeu wrote:
>
> > Resubmition of arcxcnn backliught driver adding devicetree entries
> > for all registers
> >
> > Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> >
> > ---
> > drivers/video/backlight/Kconfig | 7 +
> > drivers/video/backlight/Makefile | 1 +
> > drivers/video/backlight/arcxcnn_bl.c | 541 +++++++++++++++++++++++++++++++++++
> > include/linux/i2c/arcxcnn.h | 67 +++++
> > 4 files changed, 616 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..1dad680
> > --- /dev/null
> > +++ b/drivers/video/backlight/arcxcnn_bl.c
> > @@ -0,0 +1,541 @@
> > +/*
> > + * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
> > + *
> > + * Copyright 2016 ArcticSand, Inc.
> > + *
> > + * Licensed under the GPL-2 or later.
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
> > +#include <linux/i2c.h>
> > +#include <linux/backlight.h>
> > +#include <linux/err.h>
> > +#include <linux/of.h>
> > +#include <linux/pwm.h>
> > +#include <linux/regulator/consumer.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) external 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_LEDEN (0x06) /* LED Enable Register */
> > +#define ARCXCNN_LEDEN_ISETEXT (0x80) /* Full-scale current set externally */
> > +#define ARCXCNN_LEDEN_MASK (0x3F) /* 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_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 DEFAULT_BL_NAME "arctic_bl"
> > +#define MAX_BRIGHTNESS 4095
> > +
> > +static int s_no_reset_on_remove;
> > +module_param_named(noreset, s_no_reset_on_remove, int, 0644);
> > +MODULE_PARM_DESC(noreset, "No reset on module removal");
> > +
> > +static int s_ibright = 60;
> > +module_param_named(ibright, s_ibright, int, 0644);
> > +MODULE_PARM_DESC(ibright, "Initial brightness (when no plat data)");
> > +
> > +static int s_iledstr = 0x3F;
> > +module_param_named(iledstr, s_iledstr, int, 0644);
> > +MODULE_PARM_DESC(iledstr, "Initial LED String (when no plat data)");
> > +
> > +static int s_retries = 2; /* 1 == only one try */
> > +module_param_named(retries, s_retries, int, 0644);
> > +MODULE_PARM_DESC(retries, "I2C retries attempted");
> > +
> > +enum arcxcnn_brightness_ctrl_mode {
> > + PWM_BASED = 1,
> > + REGISTER_BASED,
> > +};
> > +
> > +struct arcxcnn;
> > +
> > +struct arcxcnn {
> > + char chipname[64];
> > + enum arcxcnn_chip_id chip_id;
> > + enum arcxcnn_brightness_ctrl_mode mode;
> > + struct i2c_client *client;
> > + struct backlight_device *bl;
> > + struct device *dev;
> > + struct arcxcnn_platform_data *pdata;
> > + struct pwm_device *pwm;
> > + struct regulator *supply; /* regulator for VDD input */
> > +};
> > +
> > +static int arcxcnn_write_byte(struct arcxcnn *lp, u8 reg, u8 data)
> > +{
> > + s32 ret = -1;
> > + int att;
> > +
> > + for (att = 0; att < s_retries; att++) {
> > + ret = i2c_smbus_write_byte_data(lp->client, reg, data);
> > + if (ret >= 0)
> > + return 0;
> > + }
> > + return ret;
> > +}
> > +
> > +static u8 arcxcnn_read_byte(struct arcxcnn *lp, u8 reg)
> > +{
> > + int val;
> > + int att;
> > +
> > + for (att = 0; att < s_retries; att++) {
> > + val = i2c_smbus_read_byte_data(lp->client, reg);
> > + if (val >= 0)
> > + return (u8)val;
> > + }
> > + return 0;
> > +}
> > +
> > +static int arcxcnn_update_bit(struct arcxcnn *lp, u8 reg, u8 mask, u8 data)
> > +{
> > + int ret, att;
> > + u8 tmp;
> > +
> > + for (att = 0, ret = -1; att < s_retries; att++) {
> > + ret = i2c_smbus_read_byte_data(lp->client, reg);
> > + if (ret >= 0)
> > + break;
> > + }
> > + 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 arcxcnn_write_byte(lp, reg, tmp);
> > +}
> > +
> > +static int arcxcnn_set_brightness(struct arcxcnn *lp, u32 brightness)
> > +{
> > + int ret;
> > + u8 val;
> > +
> > + val = (brightness & 0xF) << 4;
> > + ret = arcxcnn_write_byte(lp, ARCXCNN_WLED_ISET_LSB, val);
> > + if (ret < 0)
> > + return ret;
> > + val = (brightness >> 4);
> > + ret = arcxcnn_write_byte(lp, 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;
> > +
> > + /* set brightness */
> > + if (lp->mode == PWM_BASED)
> > + ; /* via pwm */
> > + else if (lp->mode == REGISTER_BASED)
> > + 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
> > + /* 1-3 == power save, 4 = off
> > + * 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_device *bl;
> > + struct backlight_properties props;
> > + struct arcxcnn_platform_data *pdata = lp->pdata;
> > + const char *name = pdata->name ? : DEFAULT_BL_NAME;
> > +
> > + memset(&props, 0, sizeof(props));
> > + props.type = BACKLIGHT_PLATFORM;
> > + props.max_brightness = MAX_BRIGHTNESS;
> > +
> > + if (pdata->initial_brightness > props.max_brightness)
> > + pdata->initial_brightness = props.max_brightness;
> > +
> > + props.brightness = pdata->initial_brightness;
> > +
> > + bl = devm_backlight_device_register(lp->dev, name, lp->dev, lp,
> > + &arcxcnn_bl_ops, &props);
> > + if (IS_ERR(bl))
> > + return PTR_ERR(bl);
> > +
> > + lp->bl = bl;
> > +
> > + return 0;
> > +}
> > +
> > +static ssize_t arcxcnn_get_chip_id(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_get_led_str(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->led_str);
> > +}
> > +
> > +static ssize_t arcxcnn_set_led_str(struct device *dev,
> > + struct device_attribute *attr, const char *buf, size_t len)
> > +{
> > + struct arcxcnn *lp = dev_get_drvdata(dev);
> > + unsigned long ledstr;
> > +
> > + if (kstrtoul(buf, 0, &ledstr))
> > + return 0;
> > +
> > + if (ledstr != lp->pdata->led_str) {
> > + /* don't allow 0 for ledstr, use power to turn all off */
> > + if (ledstr == 0)
> > + return 0;
> > + lp->pdata->led_str = ledstr & 0x3F;
> > + arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
> > + ARCXCNN_LEDEN_MASK, lp->pdata->led_str);
> > + }
> > + return len;
> > +}
> > +
> > +static ssize_t arcxcnn_get_bl_ctl_mode(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct arcxcnn *lp = dev_get_drvdata(dev);
> > + char *strmode = NULL;
> > +
> > + if (lp->mode == PWM_BASED)
> > + strmode = "pwm based";
> > + else if (lp->mode == REGISTER_BASED)
> > + strmode = "register based";
> > +
> > + return scnprintf(buf, PAGE_SIZE, "%s\n", strmode);
> > +}
> > +
> > +static DEVICE_ATTR(chip_id, 0444, arcxcnn_get_chip_id, NULL);
> > +static DEVICE_ATTR(led_str, 0664, arcxcnn_get_led_str, arcxcnn_set_led_str);
> > +static DEVICE_ATTR(bl_ctl_mode, 0444, arcxcnn_get_bl_ctl_mode, NULL);
> > +
> > +static struct attribute *arcxcnn_attributes[] = {
> > + &dev_attr_chip_id.attr,
> > + &dev_attr_led_str.attr,
> > + &dev_attr_bl_ctl_mode.attr,
> > + NULL,
> > +};
> > +
> > +static const struct attribute_group arcxcnn_attr_group = {
> > + .attrs = arcxcnn_attributes,
> > +};
> > +
> > +#ifdef CONFIG_OF
> > +static int arcxcnn_parse_dt(struct arcxcnn *lp)
> > +{
> > + struct device *dev = lp->dev;
> > + struct device_node *node = dev->of_node;
> > + u32 prog_val, num_entry, sources[6];
> > + int ret;
> > +
> > + if (!node) {
> > + dev_err(dev, "no platform data.\n");
> > + return -EINVAL;
> > + }
> > + lp->pdata->led_config_0_set = false;
> > + lp->pdata->led_config_1_set = false;
> > + lp->pdata->dim_freq_set = false;
> > + lp->pdata->comp_config_set = false;
> > + lp->pdata->filter_config_set = false;
> > + lp->pdata->trim_config_set = false;
> > +
> > + 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)
> > + prog_val = s_ibright;
> > + lp->pdata->initial_brightness = prog_val;
> > + if (lp->pdata->initial_brightness > MAX_BRIGHTNESS)
> > + lp->pdata->initial_brightness = MAX_BRIGHTNESS;
> > +
> > + ret = of_property_read_u32(node, "arcticsand,led-config-0", &prog_val);
> > + if (ret == 0) {
> > + lp->pdata->led_config_0 = (u8)prog_val;
> > + lp->pdata->led_config_0_set = true;
> > + }
> > + ret = of_property_read_u32(node, "arcticsand,led-config-1", &prog_val);
> > + if (ret == 0) {
> > + lp->pdata->led_config_1 = (u8)prog_val;
> > + lp->pdata->led_config_1_set = true;
> > + }
> > + ret = of_property_read_u32(node, "arcticsand,dim-freq", &prog_val);
> > + if (ret == 0) {
> > + lp->pdata->dim_freq = (u8)prog_val;
> > + lp->pdata->dim_freq_set = true;
> > + }
> > + ret = of_property_read_u32(node, "arcticsand,comp-config", &prog_val);
> > + if (ret == 0) {
> > + lp->pdata->comp_config = (u8)prog_val;
> > + lp->pdata->comp_config_set = true;
> > + }
> > + ret = of_property_read_u32(node, "arcticsand,filter-config", &prog_val);
> > + if (ret == 0) {
> > + lp->pdata->filter_config = (u8)prog_val;
> > + lp->pdata->filter_config_set = true;
> > + }
> > + ret = of_property_read_u32(node, "arcticsand,trim-config", &prog_val);
> > + if (ret == 0) {
> > + lp->pdata->trim_config = (u8)prog_val;
> > + lp->pdata->trim_config_set = true;
> > + }
> > + ret = of_property_count_u32_elems(node, "led-sources");
> > + if (ret < 0)
> > + lp->pdata->led_str = 0x3F;
> > + else {
> > + num_entry = ret;
> > + if (num_entry > 6)
> > + num_entry = 6;
> > +
> > + 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 -EINVAL;
> > + }
> > +
> > + lp->pdata->led_str = 0;
> > + while (num_entry > 0)
> > + lp->pdata->led_str |= (1 << sources[--num_entry]);
> > + }
> > + return 0;
> > +}
> > +#else
> > +static int arcxcnn_parse_dt(struct arcxcnn *lp)
> > +{
> > + return -EINVAL;
> > +}
> > +#endif
> > +
> > +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->chip_id = id->driver_data;
> > + lp->pdata = dev_get_platdata(&cl->dev);
> > +
> > + if (!lp->pdata) {
> > + lp->pdata = devm_kzalloc(lp->dev,
> > + sizeof(*lp->pdata), GFP_KERNEL);
> > + if (!lp->pdata)
> > + return -ENOMEM;
> > +
> > + /* no platform data, parse the device-tree for info. if there
> > + * is no device tree entry, we are being told we exist because
> > + * user-land said so, so make up the info we need
> > + */
> > + ret = arcxcnn_parse_dt(lp);
> > + if (ret < 0) {
> > + /* no device tree, use defaults based on module params
> > + */
> > + lp->pdata->led_config_0_set = false;
> > + lp->pdata->led_config_1_set = false;
> > + lp->pdata->dim_freq_set = false;
> > + lp->pdata->comp_config_set = false;
> > + lp->pdata->filter_config_set = false;
> > + lp->pdata->trim_config_set = false;
> > +
> > + lp->pdata->name = NULL;
> > + lp->pdata->initial_brightness = s_ibright;
> > + lp->pdata->led_str = s_iledstr;
> > + }
> > + }
> > +
> > + if (lp->pdata->dim_freq_set)
> > + lp->mode = PWM_BASED;
> > + else
> > + lp->mode = REGISTER_BASED;
> > +
> > + i2c_set_clientdata(cl, lp);
> > +
> > + /* read device ID */
> > + regval = arcxcnn_read_byte(lp, 0x1E);
> > + chipid = regval;
> > + chipid <<= 8;
> > + regval = arcxcnn_read_byte(lp, 0x1F);
> > + chipid |= regval;
> > +
> > + /* make sure it belongs to this driver
> > + * TODO - handle specific ids
> > + */
> > + if (chipid != 0x02A5) {
> > + #if 1
> > + dev_info(&cl->dev, "Chip Id is %04X\n", chipid);
> > + #else
> > + dev_err(&cl->dev, "%04X is not ARC2C\n", chipid);
> > + return -ENODEV;
> > + #endif
> > + }
> > + /* reset the device */
> > + arcxcnn_write_byte(lp, ARCXCNN_CMD, ARCXCNN_CMD_RESET);
> > +
> > + /* set initial brightness */
> > + arcxcnn_set_brightness(lp, lp->pdata->initial_brightness);
> > +
> > + /* if fadectrl set in DT, set the value directly, else leave default */
> > + if (lp->pdata->led_config_0_set)
> > + arcxcnn_write_byte(lp, ARCXCNN_FADECTRL,
> > + lp->pdata->led_config_0);
> > +
> > + /* if iled config set in DT, set the value, else internal mode */
> > + if (lp->pdata->led_config_1_set)
> > + arcxcnn_write_byte(lp, ARCXCNN_ILED_CONFIG,
> > + lp->pdata->led_config_1);
> > + else
> > + arcxcnn_write_byte(lp, ARCXCNN_ILED_CONFIG, 0x57);
> > +
> > + /* other misc DT settings */
> > + if (lp->pdata->dim_freq_set)
> > + arcxcnn_write_byte(lp, ARCXCNN_FADECTRL, lp->pdata->dim_freq);
> > + if (lp->pdata->comp_config_set)
> > + arcxcnn_write_byte(lp, ARCXCNN_COMP_CONFIG,
> > + lp->pdata->comp_config);
> > + if (lp->pdata->filter_config_set)
> > + arcxcnn_write_byte(lp, ARCXCNN_FILT_CONFIG,
> > + lp->pdata->filter_config);
> > + if (lp->pdata->trim_config_set)
> > + arcxcnn_write_byte(lp, ARCXCNN_IMAXTUNE,
> > + lp->pdata->trim_config);
> > +
> > + /* set initial LED Strings */
> > + arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
> > + ARCXCNN_LEDEN_MASK, lp->pdata->led_str);
> > +
> > + snprintf(lp->chipname, sizeof(lp->chipname),
> > + "%s-%04X", id->name, chipid);
> > +
> > + 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 (!s_no_reset_on_remove) {
> > + /* disable all strings */
> > + arcxcnn_write_byte(lp, ARCXCNN_LEDEN, 0x00);
> > + /* reset the device */
> > + arcxcnn_write_byte(lp, ARCXCNN_CMD, ARCXCNN_CMD_RESET);
> > + }
> > + lp->bl->props.brightness = 0;
> > + backlight_update_status(lp->bl);
> > + if (lp->supply)
> > + regulator_disable(lp->supply);
> > + 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);
> > +
> > +/* Note that the device/chip ID is not fixed in silicon so
> > + * auto-probing of these devices on the bus is most likely
> > + * not possible, use device tree to set i2c bus address
> > + */
> > +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 <bdodge09-1ViLX0X+lBJBDgjK7y7TUQ@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..1c681dd
> > --- /dev/null
> > +++ b/include/linux/i2c/arcxcnn.h
> > @@ -0,0 +1,67 @@
> > +/*
> > + * Backlight driver for ArcticSand ARC2C0608 Backlight Devices
> > + *
> > + * Copyright 2016 ArcticSand, Inc.
> > + *
> > + * Licensed under the GPL-2 or later.
> > + */
> > +
> > +#ifndef _ARCXCNN_H
> > +#define _ARCXCNN_H
> > +
> > +enum arcxcnn_chip_id {
> > + ARC2C0608
> > +};
> > +
> > +enum arcxcnn_brightness_source {
> > + ARCXCNN_PWM_ONLY,
> > + ARCXCNN_I2C_ONLY = 2,
> > +};
> > +
> > +#define ARCXCNN_MAX_PROGENTRIES 48 /* max a/v pairs for custom */
> > +
> > +/**
> > + * struct arcxcnn_platform_data
> > + * @name : Backlight driver name. If it is not defined, default name is set.
> > + * @initial_brightness : initial value of backlight brightness
> > + * @led_str : 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
> > + * @led_config_0_set : the value in led_config_0 is valid
> > + * @led_config_1_set : the value in led_config_1 is valid
> > + * @dim_freq_set : the value in dim_freq is valid
> > + * @comp_config_set : the value in comp_config is valid
> > + * @filter_config_set : the value in filter_config is valid
> > + * @trim_config_set : the value in trim_config is valid
> > + *
> > + * the _set flags are used to indicate that the value was explicitly set
> > + * in the device tree or platform data. settings not set are left as default
> > + * power-on default values of the chip except for led_str and led_config_1
> > + * which are set by the driver (led_str is specified indirectly in the
> > + * device tree via "led-sources")
> > + */
> > +struct arcxcnn_platform_data {
> > + const char *name;
> > + u16 initial_brightness;
> > + u8 led_str;
> > +
> > + u8 led_config_0;
> > + u8 led_config_1;
> > + u8 dim_freq;
> > + u8 comp_config;
> > + u8 filter_config;
> > + u8 trim_config;
> > +
> > + bool led_config_0_set;
> > + bool led_config_1_set;
> > + bool dim_freq_set;
> > + bool comp_config_set;
> > + bool filter_config_set;
> > + bool trim_config_set;
> > +};
> > +
> > +#endif
>
--
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: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
From: Laurent Pinchart @ 2016-11-10 8:08 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: Antti Palosaari, robh+dt@kernel.org, mark.rutland@arm.com,
mchehab@kernel.org, hverkuil@xs4all.nl,
sakari.ailus@linux.intel.com, Chris Paterson,
geert@linux-m68k.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <SG2PR06MB103893781A3AC3FAB8389DB8C3A20@SG2PR06MB1038.apcprd06.prod.outlook.com>
Antti, Hans, ping ? Please see below.
On Friday 04 Nov 2016 09:23:29 Ramesh Shanmugasundaram wrote:
> > On 11/02/2016 10:58 PM, Laurent Pinchart wrote:
> >> On Wednesday 02 Nov 2016 09:00:00 Ramesh Shanmugasundaram wrote:
> >>>>> On Wednesday 12 Oct 2016 15:10:29 Ramesh Shanmugasundaram wrote:
> >>>>>
> >>>>>> This patch adds documentation for the three new SDR formats
> >>>>>>
> >>>>>> V4L2_SDR_FMT_SCU16BE
> >>>>>> V4L2_SDR_FMT_SCU18BE
> >>>>>> V4L2_SDR_FMT_SCU20BE
> >>>
> >>> [snip]
> >>>
> >>>>>> +
> >>>>>> + - start + 0:
> >>>>>> +
> >>>>>> + - I'\ :sub:`0[D13:D6]`
> >>>>>> +
> >>>>>> + - I'\ :sub:`0[D5:D0]`
> >>>>>> +
> >>>>>> + - .. row 2
> >>>>>> +
> >>>>>> + - start + buffer_size/2:
> >>>>>> +
> >>>>>> + - Q'\ :sub:`0[D13:D6]`
> >>>>>> +
> >>>>>> + - Q'\ :sub:`0[D5:D0]`
> >>>>>
> >>>>>
> >>>>>
> >>>>> The format looks planar, does it use one V4L2 plane (as does NV12)
> >>>>> or two V4L2 planes (as does NV12M) ? Same question for the other
> >>>>> formats.
> >>>>
> >>>> Thank you for bringing up this topic. This is one of the key design
> >>>> dilemma.
> >>>>
> >>>> The I & Q data for these three SDR formats comes from two different
> >>>> DMA channels and hence two separate pointers -> we could say it is
> >>>> v4l2 multi- planar. Right now, I am making it look like a single
> >>>> plane by presenting the data in one single buffer ptr.
> >>>>
> >>>> For e.g. multi-planar SC16 format would look something like this
> >>>>
> >>>> <------------------------32bits---------------------->
> >>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 0
> >>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 4
> >>>> ...
> >>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 0
> >>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 4
> >>>>
> >>>> My concerns are
> >>>>
> >>>> 1) These formats are not a standard as the video "Image Formats".
> >>>> These formats are possible when we use DRIF + MAX2175 combination.
> >>>> If we interface with a different tuner vendor, the above format(s)
> >>>> MAY/MAY NOT be re-usable. We do not know at this point. This is the
> >>>> main open item for discussion in the cover letter.
> >>
> >> If the formats are really device-specific then they should be
> >> documented accordingly and not made generic.
> >>
> >>>> 2) MPLANE support within V4L2 seems specific to video. Please
> >>>> correct me if this is wrong interpretation.
> >>>>
> >>>> - struct v4l2_format contains v4l2_sdr_format and
> >>>> v4l2_pix_format_mplane as members of union. Should I create a new
> >>>> v4l2_sdr_format_mplane? If I have to use v4l2_pix_format_mplane most
> >>>> of the video specific members would be unused (it would be similar
> >>>> to using v4l2_pix_format itself instead of v4l2_sdr_format)?
> >>
> >> I have no answer to that question as I'm not familiar with SDR. Antti,
> >> you've added v4l2_sdr_format to the API, what's your opinion ? Hans,
> >> as you've acked the patch, your input would be appreciated as well.
> >
> > If I understood correctly this hardware provides I and Q samples via
> > different channels and driver now combines those channels as a sequential
> > IQ sample pairs.
>
> The driver combines the two buffer ptrs and present as one single buffer.
> For a buffer of size 200
>
> ptr + 0 : I I I I ... I
> ptr + 100 : Q Q Q Q ... Q
>
> > I have never seen any other than hw which provides IQ IQ IQ IQ ... IQ.
>
> There are some modes where this h/w combo can also do IQ IQ IQ pattern.
> Those modes are not added in the RFC patchset.
>
> > This is
> > I I I I ... I
> > Q Q Q Q ... Q
> > I am not very familiar with planars, but it sounds like it is correct
> > approach. So I think should be added rather than emulate packet
> > sequential format.
>
> My understanding of V4L2 MPLANE constructs is limited to a quick code read
> only. At this point MPLANE support seems specific to video. SDR is defined
> as separate format like v4l2_pix_format. Questions would be - should we
> define new SDR_MPLANE? or merge SDR format with pix format & reuse existing
> MPLANE with some SDR extensions (if possible)? These seem big design
> decisions. Any suggestions please?
>
> For my use case, MPLANE support does not seem to add significant benefit
> except it may be syntactically correct. I am doing cyclic DMA with a small
> set of h/w buffers and copying each stage to one mmapped vmalloc vb2_buffer
> at two offsets. If we add MPLANE support, it can be two non-contiguous
> buffer pointers.
>
> >>>> - The above decision (accomodate SDR & MPLANE) needs to be
> >>>> propagated across the framework. Is this the preferred approach?
> >>>>
> >>>> It goes back to point (1). As of today, the change set for this
> >>>> combo (DRIF+MAX2175) introduces new SDR formats only. Should it add
> >>>> further SDR+MPLANE support to the framework as well?
> >>>>
> >>>> I would appreciate your suggestions on this regard.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4] regulator: lp873x: Add support for populating input supply
From: Lee Jones @ 2016-11-10 8:06 UTC (permalink / raw)
To: Lokesh Vutla
Cc: Linux OMAP Mailing List, broonie-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Tero Kristo, Linux ARM Mailing List, Sekhar Nori
In-Reply-To: <20161110052915.4898-1-lokeshvutla-l0cyMroinI0@public.gmane.org>
On Thu, 10 Nov 2016, Lokesh Vutla wrote:
> In order to have a proper topology of regulators for a platform, each
> registering regulator needs to populate supply_name field for identifying
> its supply's name. Add supply_name field for lp873x regulators.
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
> ---
> Changes since v3:
> - Applied Rob's ack.
> - Sending this patch separately so that this can be merged via Regulator tree.
> - Link to v3: https://patchwork.kernel.org/patch/9408545/
>
> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> drivers/regulator/lp873x-regulator.c | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
> index 52766c2..ae9cf39 100644
> --- a/Documentation/devicetree/bindings/mfd/lp873x.txt
> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
> @@ -7,6 +7,9 @@ Required properties:
> - #gpio-cells: Should be two. The first cell is the pin number and
> the second cell is used to specify flags.
> See ../gpio/gpio.txt for more information.
> + - xxx-in-supply: Phandle to parent supply node of each regulator
> + populated under regulators node. xxx can be
> + buck0, buck1, ldo0 or ldo1.
> - regulators: List of child nodes that specify the regulator
> initialization data.
> Example:
> @@ -17,6 +20,11 @@ pmic: lp8733@60 {
> gpio-controller;
> #gpio-cells = <2>;
>
> + buck0-in-supply = <&vsys_3v3>;
> + buck1-in-supply = <&vsys_3v3>;
> + ldo0-in-supply = <&vsys_3v3>;
> + ldo1-in-supply = <&vsys_3v3>;
> +
> regulators {
> lp8733_buck0: buck0 {
> regulator-name = "lp8733-buck0";
> diff --git a/drivers/regulator/lp873x-regulator.c b/drivers/regulator/lp873x-regulator.c
> index e504b91..70e3df6 100644
> --- a/drivers/regulator/lp873x-regulator.c
> +++ b/drivers/regulator/lp873x-regulator.c
> @@ -24,6 +24,7 @@
> [_id] = { \
> .desc = { \
> .name = _name, \
> + .supply_name = _of "-in", \
> .id = _id, \
> .of_match = of_match_ptr(_of), \
> .regulators_node = of_match_ptr("regulators"),\
--
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 v2 1/3] firmware: qcom: scm: add a video command for state setting
From: Stanimir Varbanov @ 2016-11-10 8:05 UTC (permalink / raw)
To: Stephen Boyd, Stanimir Varbanov
Cc: Ohad Ben-Cohen, Bjorn Andersson, Andy Gross, Rob Herring,
Mark Rutland, Srinivas Kandagatla, linux-remoteproc, linux-kernel,
linux-arm-msm, linux-soc, devicetree
In-Reply-To: <20161110015251.GC16026@codeaurora.org>
Hi,
On 11/10/2016 03:52 AM, Stephen Boyd wrote:
> On 11/07, Stanimir Varbanov wrote:
>> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
>> index d95c70227c05..7e364691a87c 100644
>> --- a/drivers/firmware/qcom_scm.c
>> +++ b/drivers/firmware/qcom_scm.c
>> @@ -320,6 +320,22 @@ bool qcom_scm_is_available(void)
>> }
>> EXPORT_SYMBOL(qcom_scm_is_available);
>>
>> +int qcom_scm_video_set_state(u32 state, u32 spare)
>> +{
>> + int ret;
>> +
>> + ret = qcom_scm_clk_enable();
>
> Do we need clk control for this? Usually it's only required for
> crypto engine things, and turning on video doesn't sound like it
> uses crypto. I don't think downstream android kernel does this.
Correct, the crypto clk is not needed.
--
regards,
Stan
^ permalink raw reply
* [PATCH] ARM: dts: at91: sama5d3_uart: fix reg sizes to match documentation
From: Peter Rosin @ 2016-11-10 7:46 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Nicolas Ferre, Alexandre Belloni,
Jean-Christophe Plagniol-Villard, Rob Herring, Mark Rutland,
Russell King, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
The new size (0x100) also matches the size given in sama5d3.dtsi
Documentation reference: section 43.6 "Universal Asynchronous
Receiver Transmitter (UART) User Interface", table 43-4 "Register
Mapping" in [1].
[1] Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16
Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
---
arch/arm/boot/dts/sama5d3_uart.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d3_uart.dtsi b/arch/arm/boot/dts/sama5d3_uart.dtsi
index 2511d748867b..186377d41c91 100644
--- a/arch/arm/boot/dts/sama5d3_uart.dtsi
+++ b/arch/arm/boot/dts/sama5d3_uart.dtsi
@@ -55,7 +55,7 @@
uart0: serial@f0024000 {
compatible = "atmel,at91sam9260-usart";
- reg = <0xf0024000 0x200>;
+ reg = <0xf0024000 0x100>;
interrupts = <16 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart0>;
@@ -66,7 +66,7 @@
uart1: serial@f8028000 {
compatible = "atmel,at91sam9260-usart";
- reg = <0xf8028000 0x200>;
+ reg = <0xf8028000 0x100>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
--
2.1.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 v3 5/6] Documentation: bindings: add documentation for ir-spi device driver
From: Jacek Anaszewski @ 2016-11-10 7:46 UTC (permalink / raw)
To: Rob Herring
Cc: Andi Shyti, Mauro Carvalho Chehab, Sean Young, Mark Rutland,
Richard Purdie, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161109182621.ttfxtdt32q3cqce7@rob-hp-laptop>
On 11/09/2016 07:26 PM, Rob Herring wrote:
> On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote:
>> On 11/03/2016 11:10 AM, Andi Shyti wrote:
>>> Hi Jacek,
>>>
>>>> Only DT bindings of LED class drivers should be placed in
>>>> Documentation/devicetree/bindings/leds. Please move it to the
>>>> media bindings.
>>>
>>> that's where I placed it first, but Rob asked me to put it in the
>>> LED directory and Cc the LED mailining list.
>>>
>>> That's the discussion of the version 2:
>>>
>>> https://lkml.org/lkml/2016/9/12/380
>>>
>>> Rob, Jacek, could you please agree where I can put the binding?
>>
>> I'm not sure if this is a good approach. I've noticed also that
>> backlight bindings have been moved to leds, whereas they don't look
>> similarly.
>>
>> We have common.txt LED bindings, that all LED class drivers' bindings
>> have to follow. Neither backlight bindings nor these ones do that,
>> which introduces some mess.
>
> And there are probably LED bindings that don't follow common.txt either.
>
>> Eventually adding a sub-directory, e.g. remote_control could make it
>> somehow logically justified, but still - shouldn't bindings be
>> placed in the documentation directory related to the subsystem of the
>> driver they are predestined to?
>
> No. While binding directories often mirror the driver directories, they
> are not the same. Bindings are grouped by types of h/w and IR LEDs are a
> type of LED.
>
> If you prefer a sub-dir, that is fine with me.
Fine. So how about sub-dir "ir" ?
--
Best regards,
Jacek Anaszewski
--
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/2] mfd: pm8921: add support to pm8821
From: kbuild test robot @ 2016-11-10 7:41 UTC (permalink / raw)
Cc: kbuild-all, Lee Jones, Rob Herring, Andy Gross, devicetree,
linux-kernel, linux-arm-msm, linux-soc, linux-arm-kernel,
bjorn.andersson, Srinivas Kandagatla
In-Reply-To: <1478622577-20699-1-git-send-email-srinivas.kandagatla@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]
Hi Srinivas,
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.9-rc4 next-20161110]
[cannot apply to robh/for-next]
[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/Srinivas-Kandagatla/mfd-pm8921-add-support-to-pm8821/20161109-013248
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: arm-pxa_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 error/warnings (new ones prefixed by >>):
drivers/mfd/pm8921-core.c: In function 'pm8921_probe':
>> drivers/mfd/pm8921-core.c:630:58: warning: dereferencing 'void *' pointer
data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
^~
>> drivers/mfd/pm8921-core.c:630:58: error: request for member 'data' in something not a structure or union
vim +/data +630 drivers/mfd/pm8921-core.c
624 const struct pm8xxx_data *data;
625 int irq, rc;
626 unsigned int val;
627 u32 rev;
628 struct pm_irq_chip *chip;
629
> 630 data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
631 if (!data) {
632 dev_err(&pdev->dev, "No matching driver data found\n");
633 return -EINVAL;
---
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: 30088 bytes --]
^ permalink raw reply
* Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Benjamin Herrenschmidt @ 2016-11-10 7:08 UTC (permalink / raw)
To: Mark Rutland
Cc: zhichang.yuan, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, olof-nZhT3qVonbNeoWH0uzbU5w,
arnd-r2nGTMty4D4,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
lorenzo.pieralisi-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA, minyard-HInyCGIudOg,
liviu.dudau-5wv7dgnIgG8, zourongrong-Re5JQEeQqe8AvxtiuMwx3w,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w, kantyzc-9Onoh4P/yGk,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, marc.zyngier-5wv7dgnIgG8
In-Reply-To: <20161109111959.GB17020@leverpostej>
On Wed, 2016-11-09 at 11:20 +0000, Mark Rutland wrote:
> The big change would be to handle !MMIO translations, for which we'd
> need a runtime registry of ISA bus instance to find the relevant
> accessor ops and instance-specific data.
Yes. We do something a bit like that on ppc, we find the PCI bus
for which the IO ports match and I have a hook to register the
special indirect ISA.
It's a bit messy, we could do something nicer generically.
Cheers,
Ben.
--
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 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-10 6:40 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Gabriele Paoloni, mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org,
minyard-HInyCGIudOg@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org, John Garry,
will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, xuwei (O),
Linuxarm, olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
zourongrong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-fy+rA21nqHI
In-Reply-To: <2825537.ADCNsGqGxn@wuerfel>
Hi, Arnd,
On 2016/11/10 5:34, Arnd Bergmann wrote:
> On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
>>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
>>>> + /*
>>>> + * The first PCIBIOS_MIN_IO is reserved specifically for
>>> indirectIO.
>>>> + * It will separate indirectIO range from pci host bridge to
>>>> + * avoid the possible PIO conflict.
>>>> + * Set the indirectIO range directly here.
>>>> + */
>>>> + lpcdev->io_ops.start = 0;
>>>> + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
>>>> + lpcdev->io_ops.devpara = lpcdev;
>>>> + lpcdev->io_ops.pfin = hisilpc_comm_in;
>>>> + lpcdev->io_ops.pfout = hisilpc_comm_out;
>>>> + lpcdev->io_ops.pfins = hisilpc_comm_ins;
>>>> + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
>>>
>>> I have to look at patch 2 in more detail again, after missing a few
>>> review
>>> rounds. I'm still a bit skeptical about hardcoding a logical I/O port
>>> range here, and would hope that we can just go through the same
>>> assignment of logical port ranges that we have for PCI buses,
>>> decoupling
>>> the bus addresses from the linux-internal ones.
>>
>> The point here is that we want to avoid any conflict/overlap between
>> the LPC I/O space and the PCI I/O space. With the assignment above
>> we make sure that LPC never interfere with PCI I/O space.
>
> But we already abstract the PCI I/O space using dynamic registration.
> There is no need to hardcode the logical address for ISA, though
> I think we can hardcode the bus address to start at zero here.
Do you means that we can pick up the maximal I/O address from all children's
device resources??
Thanks,
Zhichang
>
> Arnd
>
> .
>
--
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 2/3] ARM64 LPC: Add missing range exception for special ISA
From: zhichang.yuan @ 2016-11-10 6:24 UTC (permalink / raw)
To: liviu.dudau@arm.com, Gabriele Paoloni
Cc: catalin.marinas@arm.com, will.deacon@arm.com, robh+dt@kernel.org,
bhelgaas@google.com, mark.rutland@arm.com, olof@lixom.net,
arnd@arndb.de, linux-arm-kernel@lists.infradead.org,
lorenzo.pieralisi@arm.com, linux-kernel@vger.kernel.org, Linuxarm,
devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
linux-serial@vger.kernel.org, minyard@acm.org, benh
In-Reply-To: <20161109165044.GE10219@e106497-lin.cambridge.arm.com>
Hi,Liviu,
Thanks for your comments!
On 2016/11/10 0:50, liviu.dudau@arm.com wrote:
> On Wed, Nov 09, 2016 at 04:16:17PM +0000, Gabriele Paoloni wrote:
>> Hi Liviu
>>
>> Thanks for reviewing
>>
>
> [removed some irrelevant part of discussion, avoid crazy formatting]
>
>>>> +/**
>>>> + * addr_is_indirect_io - check whether the input taddr is for
>>> indirectIO.
>>>> + * @taddr: the io address to be checked.
>>>> + *
>>>> + * Returns 1 when taddr is in the range; otherwise return 0.
>>>> + */
>>>> +int addr_is_indirect_io(u64 taddr)
>>>> +{
>>>> + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end <
>>> taddr)
>>>
>>> start >= taddr ?
>>
>> Nope... if (taddr < arm64_extio_ops->start || taddr > arm64_extio_ops->end)
>> then taddr is outside the range [start; end] and will return 0; otherwise
>> it will return 1...
>
> Oops, sorry, did not pay attention to the returned value. The check is
> correct as it is, no need to change then.
>
>>
>>>
>>>> + return 0;
>>>> +
>>>> + return 1;
>>>> +}
>>>>
>>>> BUILD_EXTIO(b, u8)
>>>>
>>>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>>>> index 02b2903..cc2a05d 100644
>>>> --- a/drivers/of/address.c
>>>> +++ b/drivers/of/address.c
>>>> @@ -479,6 +479,50 @@ static int of_empty_ranges_quirk(struct
>>> device_node *np)
>>>> return false;
>>>> }
>>>>
>>>> +
>>>> +/*
>>>> + * of_isa_indirect_io - get the IO address from some isa reg
>>> property value.
>>>> + * For some isa/lpc devices, no ranges property in ancestor node.
>>>> + * The device addresses are described directly in their regs
>>> property.
>>>> + * This fixup function will be called to get the IO address of
>>> isa/lpc
>>>> + * devices when the normal of_translation failed.
>>>> + *
>>>> + * @parent: points to the parent dts node;
>>>> + * @bus: points to the of_bus which can be used to parse
>>> address;
>>>> + * @addr: the address from reg property;
>>>> + * @na: the address cell counter of @addr;
>>>> + * @presult: store the address paresed from @addr;
>>>> + *
>>>> + * return 1 when successfully get the I/O address;
>>>> + * 0 will return for some failures.
>>>
>>> Bah, you are returning a signed int, why 0 for failure? Return a
>>> negative value with
>>> error codes. Otherwise change the return value into a bool.
>>
>> Yes we'll move to bool
>>
>>>
>>>> + */
>>>> +static int of_get_isa_indirect_io(struct device_node *parent,
>>>> + struct of_bus *bus, __be32 *addr,
>>>> + int na, u64 *presult)
>>>> +{
>>>> + unsigned int flags;
>>>> + unsigned int rlen;
>>>> +
>>>> + /* whether support indirectIO */
>>>> + if (!indirect_io_enabled())
>>>> + return 0;
>>>> +
>>>> + if (!of_bus_isa_match(parent))
>>>> + return 0;
>>>> +
>>>> + flags = bus->get_flags(addr);
>>>> + if (!(flags & IORESOURCE_IO))
>>>> + return 0;
>>>> +
>>>> + /* there is ranges property, apply the normal translation
>>> directly. */
>>>
>>> s/there is ranges/if we have a 'ranges'/
>>
>> Thanks for spotting this
>>
>>>
>>>> + if (of_get_property(parent, "ranges", &rlen))
>>>> + return 0;
>>>> +
>>>> + *presult = of_read_number(addr + 1, na - 1);
>>>> + /* this fixup is only valid for specific I/O range. */
>>>> + return addr_is_indirect_io(*presult);
>>>> +}
>>>> +
>>>> static int of_translate_one(struct device_node *parent, struct
>>> of_bus *bus,
>>>> struct of_bus *pbus, __be32 *addr,
>>>> int na, int ns, int pna, const char *rprop)
>>>> @@ -595,6 +639,15 @@ static u64 __of_translate_address(struct
>>> device_node *dev,
>>>> result = of_read_number(addr, na);
>>>> break;
>>>> }
>>>> + /*
>>>> + * For indirectIO device which has no ranges property, get
>>>> + * the address from reg directly.
>>>> + */
>>>> + if (of_get_isa_indirect_io(dev, bus, addr, na, &result)) {
>>>> + pr_debug("isa indirectIO matched(%s)..addr =
>>> 0x%llx\n",
>>>> + of_node_full_name(dev), result);
>>>> + break;
>>>> + }
>>>>
>>>> /* Get new parent bus and counts */
>>>> pbus = of_match_bus(parent);
>>>> @@ -688,8 +741,9 @@ static int __of_address_to_resource(struct
>>> device_node *dev,
>>>> if (taddr == OF_BAD_ADDR)
>>>> return -EINVAL;
>>>> memset(r, 0, sizeof(struct resource));
>>>> - if (flags & IORESOURCE_IO) {
>>>> + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
>>>> unsigned long port;
>>>> +
>>>> port = pci_address_to_pio(taddr);
>>>> if (port == (unsigned long)-1)
>>>> return -EINVAL;
>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>> index ba34907..1a08511 100644
>>>> --- a/drivers/pci/pci.c
>>>> +++ b/drivers/pci/pci.c
>>>> @@ -3263,7 +3263,7 @@ int __weak pci_register_io_range(phys_addr_t
>>> addr, resource_size_t size)
>>>>
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *range;
>>>> - resource_size_t allocated_size = 0;
>>>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>>>
>>>> /* check if the range hasn't been previously recorded */
>>>> spin_lock(&io_range_lock);
>>>> @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned long
>>> pio)
>>>>
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *range;
>>>> - resource_size_t allocated_size = 0;
>>>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>>
>>> Have you checked that pci_pio_to_address still returns valid values
>>> after this? I know that
>>> you are trying to take into account PCIBIOS_MIN_IO limit when
>>> allocating reserving the IO ranges,
>>> but the values added in the io_range_list are still starting from zero,
>>> no from PCIBIOS_MIN_IO,
>>
>> I think you're wrong here as in pci_address_to_pio we have:
>> + resource_size_t offset = PCIBIOS_MIN_IO;
>>
>> This should be enough to guarantee that the PIOs start at
>> PCIBIOS_MIN_IO...right?
>
> I don't think you can guarantee that the pio value that gets passed into
> pci_pio_to_address() always comes from a previously returned value by
> pci_address_to_pio(). Maybe you can add a check in pci_pio_to_address()
>
> if (pio < PCIBIOS_MIN_IO)
> return address;
>
> to avoid adding more checks in the list_for_each_entry() loop.
>
I will register some ranges to the list and test it later.
But from my understanding, pci_pio_to_address() should can return the right
original physical address.
According to the algorithm, the output PIO ranges are consecutive， just like this:
input pio of pci_pio_to_address()
|
V
|----------------|--------------------------|------|-----------|
^
|
allocated_size is here
The change of this patch just make the start PIO from ZERO to PCIBIOS_MIN_IO.
in pci_pio_to_address(), for one input pio which fall into any PIO segment, the
return address will be:
address = range->start + pio - allocated_size;
Since allocated_size is the total range size of all IO ranges before the one
where pio belong, then (pio - allocated_size) is the offset to the range start,
So....
Thanks!
Zhichang
> Best regards,
> Liviu
>
>>
>>
>>> so the calculation of the address in this function could return
>>> negative values casted to pci_addr_t.
>>>
>>> Maybe you want to adjust the range->start value in
>>> pci_register_io_range() as well to have it
>>> offset by PCIBIOS_MIN_IO as well.
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>> if (pio > IO_SPACE_LIMIT)
>>>> return address;
>>>> @@ -3335,7 +3335,7 @@ unsigned long __weak
>>> pci_address_to_pio(phys_addr_t address)
>>>> {
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *res;
>>>> - resource_size_t offset = 0;
>>>> + resource_size_t offset = PCIBIOS_MIN_IO;
>>>> unsigned long addr = -1;
>>>>
>>>> spin_lock(&io_range_lock);
>>>> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
>>>> index 3786473..deec469 100644
>>>> --- a/include/linux/of_address.h
>>>> +++ b/include/linux/of_address.h
>>>> @@ -24,6 +24,23 @@ struct of_pci_range {
>>>> #define for_each_of_pci_range(parser, range) \
>>>> for (; of_pci_range_parser_one(parser, range);)
>>>>
>>>> +
>>>> +#ifndef indirect_io_enabled
>>>> +#define indirect_io_enabled indirect_io_enabled
>>>> +static inline bool indirect_io_enabled(void)
>>>> +{
>>>> + return false;
>>>> +}
>>>> +#endif
>>>> +
>>>> +#ifndef addr_is_indirect_io
>>>> +#define addr_is_indirect_io addr_is_indirect_io
>>>> +static inline int addr_is_indirect_io(u64 taddr)
>>>> +{
>>>> + return 0;
>>>> +}
>>>> +#endif
>>>> +
>>>> /* Translate a DMA address from device space to CPU space */
>>>> extern u64 of_translate_dma_address(struct device_node *dev,
>>>> const __be32 *in_addr);
>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>>> index 0e49f70..7f6bbb6 100644
>>>> --- a/include/linux/pci.h
>>>> +++ b/include/linux/pci.h
>>>> @@ -2130,4 +2130,12 @@ static inline bool pci_ari_enabled(struct
>>> pci_bus *bus)
>>>> /* provide the legacy pci_dma_* API */
>>>> #include <linux/pci-dma-compat.h>
>>>>
>>>> +/*
>>>> + * define this macro here to refrain from compilation error for some
>>>> + * platforms. Please keep this macro at the end of this header file.
>>>> + */
>>>> +#ifndef PCIBIOS_MIN_IO
>>>> +#define PCIBIOS_MIN_IO 0
>>>> +#endif
>>>> +
>>>> #endif /* LINUX_PCI_H */
>>>> --
>>>> 1.9.1
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci"
>>> in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv2 2/2] gpio: xilinx: Add clock support
From: Shubhrajyoti Datta @ 2016-11-10 6:08 UTC (permalink / raw)
To: Sören Brinkmann
Cc: Shubhrajyoti Datta, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Michal Simek
In-Reply-To: <20161109171852.GC14444@xsjsorenbubuntu>
On Wed, Nov 9, 2016 at 10:48 PM, Sören Brinkmann
<soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
[...]
>>
>> My idea was to keep the clk name optional since there is only one clock.
>> Or do you think we should mandate the name if clk is provided.
>
> I'd make 'clock-names' mandatory if 'clocks' is present. That way there
> won't be any trouble if this IP ever consumed additional clocks in the
> future.
fixed that in v3.
Thanks
>
> Sören
--
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
* [PATCHv3 2/2] gpio: xilinx: Add clock support
From: Shubhrajyoti Datta @ 2016-11-10 5:56 UTC (permalink / raw)
To: linux-gpio, devicetree
Cc: soren.brinkmann, michal.simek, shubhrajyoti.datta,
Shubhrajyoti Datta
In-Reply-To: <1478757365-3311-1-git-send-email-shubhrajyoti.datta@xilinx.com>
Add basic clock support for xilinx gpio.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
---
v2 :
no change
v3:
Add clock name
Remove some debug messages
drivers/gpio/gpio-xilinx.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index 14b2a62..3385a0a 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -13,6 +13,7 @@
*/
#include <linux/bitops.h>
+#include <linux/clk.h>
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/module.h>
@@ -45,6 +46,7 @@
* @gpio_state: GPIO state shadow register
* @gpio_dir: GPIO direction shadow register
* @gpio_lock: Lock used for synchronization
+ * @clk: Clock resource for this controller
*/
struct xgpio_instance {
struct of_mm_gpio_chip mmchip;
@@ -52,6 +54,7 @@ struct xgpio_instance {
u32 gpio_state[2];
u32 gpio_dir[2];
spinlock_t gpio_lock[2];
+ struct clk *clk;
};
static inline int xgpio_index(struct xgpio_instance *chip, int gpio)
@@ -282,6 +285,7 @@ static int xgpio_remove(struct platform_device *pdev)
struct xgpio_instance *chip = platform_get_drvdata(pdev);
of_mm_gpiochip_remove(&chip->mmchip);
+ clk_disable_unprepare(chip->clk);
return 0;
}
@@ -307,6 +311,21 @@ static int xgpio_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, chip);
+ /* Retrieve GPIO clock */
+ chip->clk = devm_clk_get(&pdev->dev, "s_axi_aclk");
+ if (IS_ERR(chip->clk)) {
+ if (PTR_ERR(chip->clk) == -ENOENT)
+ chip->clk = NULL;
+ else
+ return PTR_ERR(chip->clk);
+ }
+
+ status = clk_prepare_enable(chip->clk);
+ if (status) {
+ dev_err(&pdev->dev, "Unable to enable clock.\n");
+ return status;
+ }
+
/* Update GPIO state shadow register with default value */
of_property_read_u32(np, "xlnx,dout-default", &chip->gpio_state[0]);
@@ -362,6 +381,7 @@ static int xgpio_probe(struct platform_device *pdev)
if (status) {
pr_err("%s: error in probe function with status %d\n",
np->full_name, status);
+ clk_disable_unprepare(chip->clk);
return status;
}
--
1.7.1
^ permalink raw reply related
* [PATCHv3 1/2] gpio: xilinx: dt-binding: Add clock node
From: Shubhrajyoti Datta @ 2016-11-10 5:56 UTC (permalink / raw)
To: linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA,
shubhrajyoti.datta-Re5JQEeQqe8AvxtiuMwx3w, Shubhrajyoti Datta
Add the clock node to the dt binding.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
---
v2:
Make clocks optional
Add clock name
v3:
No change
.../devicetree/bindings/gpio/gpio-xilinx.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
index 63bf4be..1372007 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
@@ -25,12 +25,16 @@ Optional properties:
- xlnx,dout-default-2 : as above but the second channel
- xlnx,gpio2-width : as above but for the second channel
- xlnx,tri-default-2 : as above but for the second channel
+- clocks: Input clock specifier. Refer to common clock bindings.
+- clock-names: Input clock name, should be s_axi_aclk.
Example:
gpio: gpio@40000000 {
#gpio-cells = <2>;
compatible = "xlnx,xps-gpio-1.00.a";
+ clocks = <&clkc 15>;
+ clock-names = "s_axi_aclk";
gpio-controller ;
interrupt-parent = <µblaze_0_intc>;
interrupts = < 6 2 >;
--
1.7.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 related
* [PATCH] dt-binding: remoteproc: Introduce ADSP loader binding
From: Bjorn Andersson @ 2016-11-10 5:50 UTC (permalink / raw)
To: Ohad Ben-Cohen, Bjorn Andersson, Rob Herring, Mark Rutland
Cc: linux-remoteproc, devicetree, linux-kernel, linux-arm-msm,
Sarangdhar Joshi
This document defines the binding for a component that loads firmware
and control the life cycle of the Qualcomm ADSP Hexagon core.
Cc: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v2:
- Added the required "xo" clock, from Sarangdhar
- Added smd-edge node
- Corrected example
Changes since v1:
- Added platform names to compatible
.../devicetree/bindings/remoteproc/qcom,adsp.txt | 98 ++++++++++++++++++++++
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
new file mode 100644
index 000000000000..471946f2f080
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -0,0 +1,98 @@
+Qualcomm ADSP Peripheral Image Loader
+
+This document defines the binding for a component that loads and boots firmware
+on the Qualcomm ADSP Hexagon core.
+
+- compatible:
+ Usage: required
+ Value type: <string>
+ Definition: must be one of:
+ "qcom,msm8974-adsp-pil"
+ "qcom,msm8996-adsp-pil"
+
+- interrupts-extended:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: must list the watchdog, fatal IRQs ready, handover and
+ stop-ack IRQs
+
+- interrupt-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
+
+- clocks:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: reference to the xo clock to be held on behalf of the
+ booting Hexagon core
+
+- clock-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: must be "xo"
+
+- cx-supply:
+ Usage: required
+ Value type: <phandle>
+ Definition: reference to the regulator to be held on behalf of the
+ booting Hexagon core
+
+- memory-region:
+ Usage: required
+ Value type: <phandle>
+ Definition: reference to the reserved-memory for the ADSP
+
+- qcom,smem-states:
+ Usage: required
+ Value type: <phandle>
+ Definition: reference to the smem state for requesting the ADSP to
+ shut down
+
+- qcom,smem-state-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: must be "stop"
+
+
+= SUBNODES
+The adsp node may have an subnode named "smd-edge" that describes the SMD edge,
+channels and devices related to the ADSP. See ../soc/qcom/qcom,smd.txt for
+details on how to describe the SMD edge.
+
+
+= EXAMPLE
+The following example describes the resources needed to boot control the
+ADSP, as it is found on MSM8974 boards.
+
+ adsp {
+ compatible = "qcom,msm8974-adsp-pil";
+
+ interrupts-extended = <&intc 0 162 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack";
+
+ clocks = <&rpmcc RPM_CXO_CLK>;
+ clock-names = "xo";
+
+ cx-supply = <&pm8841_s2>;
+
+ memory-region = <&adsp_region>;
+
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ smd-edge {
+ interrupts = <0 156 IRQ_TYPE_EDGE_RISING>;
+
+ qcom,ipc = <&apcs 8 8>;
+ qcom,smd-edge = <1>;
+ };
+ };
--
2.5.0
^ permalink raw reply related
* [PATCH v4] regulator: lp873x: Add support for populating input supply
From: Lokesh Vutla @ 2016-11-10 5:29 UTC (permalink / raw)
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, Linux OMAP Mailing List
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Tero Kristo,
Linux ARM Mailing List, Sekhar Nori, Lokesh Vutla
In order to have a proper topology of regulators for a platform, each
registering regulator needs to populate supply_name field for identifying
its supply's name. Add supply_name field for lp873x regulators.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
---
Changes since v3:
- Applied Rob's ack.
- Sending this patch separately so that this can be merged via Regulator tree.
- Link to v3: https://patchwork.kernel.org/patch/9408545/
Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
drivers/regulator/lp873x-regulator.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
index 52766c2..ae9cf39 100644
--- a/Documentation/devicetree/bindings/mfd/lp873x.txt
+++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
@@ -7,6 +7,9 @@ Required properties:
- #gpio-cells: Should be two. The first cell is the pin number and
the second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
+ - xxx-in-supply: Phandle to parent supply node of each regulator
+ populated under regulators node. xxx can be
+ buck0, buck1, ldo0 or ldo1.
- regulators: List of child nodes that specify the regulator
initialization data.
Example:
@@ -17,6 +20,11 @@ pmic: lp8733@60 {
gpio-controller;
#gpio-cells = <2>;
+ buck0-in-supply = <&vsys_3v3>;
+ buck1-in-supply = <&vsys_3v3>;
+ ldo0-in-supply = <&vsys_3v3>;
+ ldo1-in-supply = <&vsys_3v3>;
+
regulators {
lp8733_buck0: buck0 {
regulator-name = "lp8733-buck0";
diff --git a/drivers/regulator/lp873x-regulator.c b/drivers/regulator/lp873x-regulator.c
index e504b91..70e3df6 100644
--- a/drivers/regulator/lp873x-regulator.c
+++ b/drivers/regulator/lp873x-regulator.c
@@ -24,6 +24,7 @@
[_id] = { \
.desc = { \
.name = _name, \
+ .supply_name = _of "-in", \
.id = _id, \
.of_match = of_match_ptr(_of), \
.regulators_node = of_match_ptr("regulators"),\
--
2.10.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 related
* Re: [v16, 0/7] Fix eSDHC host version register bug
From: Scott Wood @ 2016-11-10 5:17 UTC (permalink / raw)
To: Y.B. Lu, Ulf Hansson
Cc: linux-mmc, Arnd Bergmann, linuxppc-dev@lists.ozlabs.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-clk,
iommu@lists.linux-foundation.org, netdev@vger.kernel.org,
Greg Kroah-Hartman, Mark Rutland, Rob Herring, Russell King,
Jochen Friedrich, Joerg Roedel, Claudiu Manoil
In-Reply-To: <DB6PR0401MB25369DEFDDDED2A96851259EF8B80@DB6PR0401MB2536.eurprd04.prod.outlook.com>
On Thu, 2016-11-10 at 04:11 +0000, Y.B. Lu wrote:
> >
> > -----Original Message-----
> > From: Y.B. Lu
> > Sent: Thursday, November 10, 2016 12:06 PM
> > To: 'Scott Wood'; Ulf Hansson
> > Cc: linux-mmc; Arnd Bergmann; linuxppc-dev@lists.ozlabs.org;
> > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> > kernel@vger.kernel.org; linux-clk; iommu@lists.linux-foundation.org;
> > netdev@vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> > Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> > Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > Subject: RE: [v16, 0/7] Fix eSDHC host version register bug
> >
> > >
> > > -----Original Message-----
> > > From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc-
> > > owner@vger.kernel.org] On Behalf Of Scott Wood
> > > Sent: Thursday, November 10, 2016 11:55 AM
> > > To: Ulf Hansson; Y.B. Lu
> > > Cc: linux-mmc; Arnd Bergmann; linuxppc-dev@lists.ozlabs.org;
> > > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > > linux- kernel@vger.kernel.org; linux-clk;
> > > iommu@lists.linux-foundation.org; netdev@vger.kernel.org; Greg
> > > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > > Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > > Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
> > >
> > > On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > > >
> > > > - i2c-list
> > > >
> > > > On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > > > >
> > > > >
> > > > > This patchset is used to fix a host version register bug in the
> > > > > T4240-
> > > > > R1.0-R2.0
> > > > > eSDHC controller. To match the SoC version and revision, 15
> > > > > previous version patchsets had tried many methods but all of them
> > > > > were rejected by reviewers.
> > > > > Such as
> > > > > - dts compatible method
> > > > > - syscon method
> > > > > - ifdef PPC method
> > > > > - GUTS driver getting SVR method Anrd suggested a
> > > > > soc_device_match method in v10, and this is the only available
> > > > > method left now. This v11 patchset introduces the soc_device_match
> > > > > interface in soc driver.
> > > > >
> > > > > The first four patches of Yangbo are to add the GUTS driver. This
> > > > > is used to register a soc device which contain soc version and
> > > > > revision information.
> > > > > The other three patches introduce the soc_device_match method in
> > > > > soc driver and apply it on esdhc driver to fix this bug.
> > > > >
> > > > > ---
> > > > > Changes for v15:
> > > > > - Dropped patch 'dt: bindings: update Freescale DCFG
> > > compatible'
> > > >
> > > > >
> > > > > since the work had been done by below patch on
> > > > > ShawnGuo's linux tree.
> > > > > 'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A
> > > > > compatible for SCFG
> > > > > and DCFG'
> > > > > - Fixed error code issue in guts driver Changes for v16:
> > > > > - Dropped patch 'powerpc/fsl: move mpc85xx.h to
> > > include/linux/fsl'
> > > >
> > > > >
> > > > > - Added a bug-fix patch from Geert
> > > > > ---
> > > > >
> > > > > Arnd Bergmann (1):
> > > > > base: soc: introduce soc_device_match() interface
> > > > >
> > > > > Geert Uytterhoeven (1):
> > > > > base: soc: Check for NULL SoC device attributes
> > > > >
> > > > > Yangbo Lu (5):
> > > > > ARM64: dts: ls2080a: add device configuration node
> > > > > dt: bindings: move guts devicetree doc out of powerpc directory
> > > > > soc: fsl: add GUTS driver for QorIQ platforms
> > > > > MAINTAINERS: add entry for Freescale SoC drivers
> > > > > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > > > >
> > > > > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > > > > MAINTAINERS | 11 +-
> > > > > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > > > > drivers/base/Kconfig | 1 +
> > > > > drivers/base/soc.c | 70 ++++++
> > > > > drivers/mmc/host/Kconfig | 1 +
> > > > > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > > > > drivers/soc/Kconfig | 3 +-
> > > > > drivers/soc/fsl/Kconfig | 18 ++
> > > > > drivers/soc/fsl/Makefile | 1 +
> > > > > drivers/soc/fsl/guts.c | 236
> > > > > +++++++++++++++++++++
> > > > > include/linux/fsl/guts.h | 125
> > > > > ++++++-----
> > > > > include/linux/sys_soc.h | 3 +
> > > > > 13 files changed, 447 insertions(+), 51 deletions(-)
> > > > > rename Documentation/devicetree/bindings/{powerpc =>
> > > > > soc}/fsl/guts.txt
> > > > > (91%)
> > > > > create mode 100644 drivers/soc/fsl/Kconfig
> > > > > create mode 100644 drivers/soc/fsl/guts.c
> > > > >
> > > > > --
> > > > > 2.1.0.27.g96db324
> > > > >
> > > > Thanks, applied on my mmc tree for next!
> > > >
> > > > I noticed that some DT compatibles weren't documented, according to
> > > > checkpatch. Please fix that asap!
> > > They are documented, in fsl/guts.txt (the file moved in patch 2/7):
> > > >
> > > > - compatible : Should define the compatible device type for
> > > > global-utilities.
> > > > Possible compatibles:
> > > > "fsl,qoriq-device-config-1.0"
> > > > "fsl,qoriq-device-config-2.0"
> > > > "fsl,<chip>-device-config"
> > > > "fsl,<chip>-guts"
> > > Checkpatch doesn't understand compatibles defined in such a way.
> > [Lu Yangbo-B47093] You're right, Scott. I dropped DT patch 'dt: bindings:
> > update Freescale DCFG compatible '
> > which fixed un-doc issue since Shaohui had done this on Shawn Guo's tree.
> > https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h
> > =imx/dt64&id=981034a2bfcaff5c95dafde24d7abfe7f9025c19
> >
> > Thanks.
> [Lu Yangbo-B47093] Both 'fsl,<chip>-guts' and 'fsl,<chip>-dcfg' would have
> no un-doc issue after Shaohui's patch are pulled :)
I don't follow. The link above points to a patch that addresses -dcfg and
-scfg, not -device-config or -guts -- and it also doesn't do it in a manner
that checkpatch will understand.
In any case, I wouldn't call this an "un-doc issue" -- it is documented -- but
rather a checkpatch-friendliness issue.
-Scott
^ permalink raw reply
* [PATCH v2 5/5] arm: dts: am57xx-idk-common: Add overide powerhold property
From: Keerthy @ 2016-11-10 5:09 UTC (permalink / raw)
To: tony, lee.jones, robh+dt
Cc: linux-omap, linux-kernel, devicetree, linux-gpio, nm, j-keerthy,
t-kristo
In-Reply-To: <1478754560-27923-1-git-send-email-j-keerthy@ti.com>
The PMICs have POWERHOLD set by default which prevents PMIC shutdown
even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
So to enable pmic power off this property lets one over ride the default
value and enable pmic power off.
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
arch/arm/boot/dts/am57xx-idk-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 03cec62..6e7db63 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -57,6 +57,7 @@
#interrupt-cells = <2>;
interrupt-controller;
ti,system-power-controller;
+ ti,palmas-override-powerhold;
tps659038_pmic {
compatible = "ti,tps659038-pmic";
--
1.9.1
^ permalink raw reply related
* [PATCH v2 4/5] arm: dts: am57xx-beagle-x15-common: Add overide powerhold property
From: Keerthy @ 2016-11-10 5:09 UTC (permalink / raw)
To: tony, lee.jones, robh+dt
Cc: linux-omap, linux-kernel, devicetree, linux-gpio, nm, j-keerthy,
t-kristo
In-Reply-To: <1478754560-27923-1-git-send-email-j-keerthy@ti.com>
The PMICs have POWERHOLD set by default which prevents PMIC shutdown
even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
So to enable pmic power off this property lets one over ride the default
value and enable pmic power off.
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 6df7829..78bee26 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -204,6 +204,7 @@
interrupt-controller;
ti,system-power-controller;
+ ti,palmas-override-powerhold;
tps659038_pmic {
compatible = "ti,tps659038-pmic";
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/5] mfd: palmas: Reset the POWERHOLD mux during power off
From: Keerthy @ 2016-11-10 5:09 UTC (permalink / raw)
To: tony-4v6yS6AI5VpBDgjK7y7TUQ, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, nm-l0cyMroinI0,
j-keerthy-l0cyMroinI0, t-kristo-l0cyMroinI0
In-Reply-To: <1478754560-27923-1-git-send-email-j-keerthy-l0cyMroinI0@public.gmane.org>
POWERHOLD signal has higher priority over the DEV_ON bit.
So power off will not happen if the POWERHOLD is held high.
Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
and the DEV_ON bit to take effect to power off the PMIC.
PMIC Power off happens in dire situations like thermal shutdown
so irrespective of the POWERHOLD setting go ahead and turn off
the powerhold. Currently poweroff is broken on boards that have
powerhold enabled. This fixes poweroff on those boards.
Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
---
Changes in v2:
* Changed pr_err to dev_err
* removed redundant boolean variable override-powerhold
drivers/mfd/palmas.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index ee9e9ea..da90124 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -430,6 +430,20 @@ static void palmas_power_off(void)
{
unsigned int addr;
int ret, slave;
+ struct device_node *np = palmas_dev->dev->of_node;
+
+ if (of_property_read_bool(np, "ti,palmas-override-powerhold")) {
+ addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
+ PALMAS_PRIMARY_SECONDARY_PAD2);
+ slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
+
+ ret = regmap_update_bits(palmas_dev->regmap[slave], addr,
+ PALMAS_PRIMARY_SECONDARY_PAD2_GPIO_7_MASK, 0);
+ if (ret)
+ dev_err(palmas_dev->dev,
+ "Unable to write PRIMARY_SECONDARY_PAD2 %d\n",
+ ret);
+ }
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);
--
1.9.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 related
* [PATCH v2 2/5] mfd: palmas: Remove redundant check in palmas_power_off
From: Keerthy @ 2016-11-10 5:09 UTC (permalink / raw)
To: tony, lee.jones, robh+dt
Cc: linux-omap, linux-kernel, devicetree, linux-gpio, nm, j-keerthy,
t-kristo
In-Reply-To: <1478754560-27923-1-git-send-email-j-keerthy@ti.com>
palmas_dev and palmas_power_off are always assigned together.
So the check for palmas_dev inside palmas_power_off function
is redundant. Removing the same.
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
drivers/mfd/palmas.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 8f8bacb..ee9e9ea 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -431,9 +431,6 @@ static void palmas_power_off(void)
unsigned int addr;
int ret, slave;
- if (!palmas_dev)
- return;
-
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/5] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
From: Keerthy @ 2016-11-10 5:09 UTC (permalink / raw)
To: tony, lee.jones, robh+dt
Cc: linux-omap, linux-kernel, devicetree, linux-gpio, nm, j-keerthy,
t-kristo
In-Reply-To: <1478754560-27923-1-git-send-email-j-keerthy@ti.com>
GPIO7 is configured in POWERHOLD mode which has higher priority
over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
bit is turned off. This property enables driver to over ride the
POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
scenarios.
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
index caf297b..c28d4eb8 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
@@ -35,6 +35,15 @@ Optional properties:
- ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode.
Selection primary or secondary function associated to GPADC_START
and SYSEN2 pin/pad for DVFS2 interface
+- ti,palmas-override-powerhold: This is applicable for PMICs for which
+ GPIO7 is configured in POWERHOLD mode which has higher priority
+ over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
+ bit is turned off. This property enables driver to over ride the
+ POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
+ scenarios. So for GPIO7 if ti,palmas-override-powerhold is set
+ then the GPIO_7 field should never be muxed to anything else.
+ It should be set to POWERHOLD by default and only in case of
+ power off scenarios the driver will over ride the mux value.
This binding uses the following generic properties as defined in
pinctrl-bindings.txt:
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/5] mfd: palmas: add powerhold overriding during power off
From: Keerthy @ 2016-11-10 5:09 UTC (permalink / raw)
To: tony, lee.jones, robh+dt
Cc: linux-omap, linux-kernel, devicetree, linux-gpio, nm, j-keerthy,
t-kristo
The series lets one over powerhold for pmic.
The powerhold is used to keep the pmic power on even
after the DEV_CTRL On bit is set to off.
Tested on am572x-idk board, dra72-evm, dra7-evm for poweroff.
Keerthy (5):
Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override
property definition
mfd: palmas: Remove redundant check in palmas_power_off
mfd: palmas: Reset the POWERHOLD mux during power off
arm: dts: am57xx-beagle-x15-common: Add overide powerhold property
arm: dts: am57xx-idk-common: Add overide powerhold property
.../devicetree/bindings/pinctrl/pinctrl-palmas.txt | 9 +++++++++
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 1 +
arch/arm/boot/dts/am57xx-idk-common.dtsi | 1 +
drivers/mfd/palmas.c | 15 +++++++++++++--
4 files changed, 24 insertions(+), 2 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH 2/4] mfd: palmas: Reset the POWERHOLD mux during power off
From: Keerthy @ 2016-11-10 4:18 UTC (permalink / raw)
To: Lee Jones
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, nm-l0cyMroinI0,
t-kristo-l0cyMroinI0
In-Reply-To: <20161109161419.GJ13127@dell>
On Wednesday 09 November 2016 09:44 PM, Lee Jones wrote:
> On Thu, 27 Oct 2016, Keerthy wrote:
>
>> POWERHOLD signal has higher priority over the DEV_ON bit.
>> So power off will not happen if the POWERHOLD is held high.
>> Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
>> and the DEV_ON bit to take effect to power off the PMIC.
>>
>> PMIC Power off happens in dire situations like thermal shutdown
>> so irrespective of the POWERHOLD setting go ahead and turn off
>> the powerhold. Currently poweroff is broken on boards that have
>> powerhold enabled. This fixes poweroff on those boards.
>>
>> Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
>> ---
>> drivers/mfd/palmas.c | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
>> index 8f8bacb..8fbc5e0 100644
>> --- a/drivers/mfd/palmas.c
>> +++ b/drivers/mfd/palmas.c
>> @@ -430,10 +430,28 @@ static void palmas_power_off(void)
>> {
>> unsigned int addr;
>> int ret, slave;
>> + struct device_node *node;
>> + bool override_powerhold;
>>
>> if (!palmas_dev)
>
> Can this happen?
pm_power_off and palmas_dev are always assigned together. You are right
this is redundant and can be removed.
>
>> return;
>>
>> + node = palmas_dev->dev->of_node;
>
> Just do:
>
> struct device_node *np = palmas_dev->dev->of_node;
>
>> + override_powerhold = of_property_read_bool(node,
>> + "ti,palmas-override-powerhold");
>
> Break the line after the '=' instead.
okay.
>
>> + if (override_powerhold) {
>
> if (of_property_read_bool(node, "ti,palmas-override-powerhold"))
>
> Then remove 'override_powerhold'.
Okay.
>
>> + addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
>> + PALMAS_PRIMARY_SECONDARY_PAD2);
>> + slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
>> +
>> + ret = regmap_update_bits(palmas_dev->regmap[slave], addr,
>> + PALMAS_PRIMARY_SECONDARY_PAD2_GPIO_7_MASK, 0);
>> + if (ret)
>> + pr_err("%s: Unable to write PALMAS_PRIMARY_SECONDARY_PAD2 %d\n",
>> + __func__, ret);
>
> Don't use __func__ in live code.
okay.
>
> And use dev_err();
sure.
>
>
>> + }
>> +
>> slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
>> addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);
>>
>
--
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