* Re: [PATCH v5 0/8] Add dual-role OTG support for Allwinner H3
From: Maxime Ripard @ 2017-03-27 11:47 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Icenowy Zheng, Rob Herring, Chen-Yu Tsai,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <73c148dd-fe21-da12-45d1-0c70d9a5b998-l0cyMroinI0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]
On Mon, Mar 27, 2017 at 03:35:25PM +0530, Kishon Vijay Abraham I wrote:
>
>
> On Saturday 25 March 2017 08:20 PM, Icenowy Zheng wrote:
> > Allwinner H3 have a its USB PHY0 routed to two USB controllers: one is
> > a MUSB controller, which can work in peripheral mode, but works badly in
> > host mode (several hardware will fail on the MUSB controller, even connect
> > one MUSB controller in peripheral mode to another one in host mode cannot
> > work); the other is a pair of EHCI/OHCI controller, which can work only
> > in host mode, but have better compatibillity. The route is controlled in
> > a register, which we have set it to HCI only when we do not know about
> > it well.
> >
> > Add support to route to the best controller according to current USB mode
> > (host/peripheral).
> >
> > Note: Currently even if hardware only support hostmode, we should still
> > enable the MUSB controller, as it controls the USB mode. (Some this kind
> > of hardware can also work in peripheral mode by settings in the sysfs
> > node of MUSB, then connect it to another host via a USB Type-A to Type-A
> > cable.)
> >
> > Patch 1 changes the device tree binding to include the "pmu0" for HCI pair.
> >
> > Patch 2 and 3 are fixes for H3 PHY, in order to make MUSB really working
> > on H3.
> >
> > Patch 4 adds support for auto routing of PHY0. It's currently only enabled
> > on H3, but it's easy to extend it to other SoCs which feature this
> > route control.
>
> merged the 1st four patch of this series.
And applied the last four.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/3] device property: Move FW type specific functionality to FW specific files
From: Mika Westerberg @ 2017-03-27 11:31 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, devicetree, robh, sudeep.holla, lorenzo.pieralisi,
rafael, mark.rutland, broonie, ahs3, frowand.list
In-Reply-To: <1490353432-12017-1-git-send-email-sakari.ailus@linux.intel.com>
On Fri, Mar 24, 2017 at 01:03:50PM +0200, Sakari Ailus wrote:
> +static int acpi_fwnode_property_read_int_array(
This is really ugly way to split arguments into multiple lines IMHO.
> + struct fwnode_handle *fwnode, const char *propname,
> + unsigned int elem_size, void *val, size_t nval)
I would much more see something like:
static int
acpi_fwnode_property_read_int_array(struct fwnode_handle *fwnode,
const char *propname, unsigned int elem_size, void *val, size_t nval)
or even
static int
acpi_fwnode_property_read_int_array(struct fwnode_handle *fwnode,
const char *propname,
unsigned int elem_size,
void *val, size_t nval)
ditto for all occurences.
Other than that this patch looks reasonable to me.
^ permalink raw reply
* Re: [PATCH 1/1] device property: Read strings using string array reading functions
From: Mika Westerberg @ 2017-03-27 11:11 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi, devicetree, sudeep.holla, lorenzo.pieralisi, rafael,
mark.rutland, broonie, robh, ahs3
In-Reply-To: <1490347486-9604-1-git-send-email-sakari.ailus@linux.intel.com>
On Fri, Mar 24, 2017 at 11:24:46AM +0200, Sakari Ailus wrote:
> drivers/base/property.c | 47 ++---------------------------------------------
> 1 file changed, 2 insertions(+), 45 deletions(-)
This tells it all :)
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
^ permalink raw reply
* Re: [PATCH] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Michael Hennerich @ 2017-03-27 11:07 UTC (permalink / raw)
To: Peter Rosin, wsa, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel
In-Reply-To: <5e4b224d-4dba-e183-4eda-d68f57faff7e@axentia.se>
On 24.03.2017 09:01, Peter Rosin wrote:
> On 2017-03-23 15:22, michael.hennerich@analog.com wrote:
>> From: Michael Hennerich <michael.hennerich@analog.com>
>>
>> This patch adds support for the Analog Devices / Linear Technology
>> LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
>> The LTC4306 optionally provides two general purpose input/output pins
>> (GPIOs) that can be configured as logic inputs, opendrain outputs or
>> push-pull outputs via the generic GPIOLIB framework.
Hi Peter,
Thanks for your review.
>
> Hmmm, I'm not sure if it is ok to implement a gpio provider outside of
> drivers/gpio like this? Should it be done with MFD, or is that just
> adding needless complexity?
Its not uncommon to have these small gpiochips inside the driver which
implements the primary function. Linus is on the To list to add his review.
>
> I also wonder if you have thought about implementing support for
> alerts? And do you need recovery if things get stuck? I see timeout
> bits and failure to connect bits in the register map...
The irq_chip handling the ALERTs will be added in future. However I
don't think the chip internal timeout handling will be exposed. I would
assume the parent adapter handles timeouts on the connected downstream
ports.
>
>>
>> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
>> ---
>> .../devicetree/bindings/i2c/i2c-mux-ltc4306.txt | 61 ++++
>> MAINTAINERS | 8 +
>> drivers/i2c/muxes/Kconfig | 10 +
>> drivers/i2c/muxes/Makefile | 1 +
>> drivers/i2c/muxes/i2c-mux-ltc4306.c | 365 +++++++++++++++++++++
>> 5 files changed, 445 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
>> create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
>> new file mode 100644
>> index 0000000..1e98c6b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
>> @@ -0,0 +1,61 @@
>> +* Linear Technology / Analog Devices I2C bus switch
>> +
>> +Required Properties:
>> +
>> + - compatible: Must contain one of the following.
>> + "lltc,ltc4305", "lltc,ltc4306"
>> + - reg: The I2C address of the device.
>> +
>> + The following required properties are defined externally:
>> +
>> + - Standard I2C mux properties. See i2c-mux.txt in this directory.
>> + - I2C child bus nodes. See i2c-mux.txt in this directory.
>> +
>> +Optional Properties:
>> +
>> + - enable-gpios: Reference to the GPIO connected to the enable input.
>> + - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
>> + children in idle state. This is necessary for example, if there are several
>> + multiplexers on the bus and the devices behind them use same I2C addresses.
>> + - gpio-controller: Marks the device node as a GPIO Controller.
>> + - #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.
>> + - ltc,downstream-accelerators-enable: Enables the rise time accelerators
>> + on the downstream port.
>> + - ltc,upstream-accelerators-enable: Enables the rise time accelerators
>> + on the upstream port.
>> +
>> +Example:
>> +
>> + ltc4306: i2c-mux@4a {
>> + compatible = "lltc,ltc4306";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0x4a>;
>> +
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + i2c@0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + eeprom@50 {
>> + compatible = "at,24c02";
>> + reg = <0x50>;
>> + };
>> + };
>> +
>> + i2c@1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + eeprom@50 {
>> + compatible = "at,24c02";
>> + reg = <0x50>;
>> + };
>> + };
>> + };
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index c776906..9a27a19 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7698,6 +7698,14 @@ S: Maintained
>> F: Documentation/hwmon/ltc4261
>> F: drivers/hwmon/ltc4261.c
>>
>> +LTC4306 I2C MULTIPLEXER DRIVER
>> +M: Michael Hennerich <michael.hennerich@analog.com>
>> +W: http://ez.analog.com/community/linux-device-drivers
>> +L: linux-i2c@vger.kernel.org
>> +S: Supported
>> +F: drivers/i2c/muxes/i2c-mux-ltc4306.c
>> +F: Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
>> +
>> LTP (Linux Test Project)
>> M: Mike Frysinger <vapier@gentoo.org>
>> M: Cyril Hrubis <chrubis@suse.cz>
>> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
>> index 10b3d17..f501b3b 100644
>> --- a/drivers/i2c/muxes/Kconfig
>> +++ b/drivers/i2c/muxes/Kconfig
>> @@ -30,6 +30,16 @@ config I2C_MUX_GPIO
>> This driver can also be built as a module. If so, the module
>> will be called i2c-mux-gpio.
>>
>> +config I2C_MUX_LTC4306
>> + tristate "LTC LTC4306/5 I2C multiplexer"
>> + select GPIOLIB
>> + help
>> + If you say yes here you get support for the LTC LTC4306 or LTC4305
>> + I2C mux/switch devices.
>> +
>> + This driver can also be built as a module. If so, the module
>> + will be called i2c-mux-ltc4306.
>> +
>> config I2C_MUX_PCA9541
>> tristate "NXP PCA9541 I2C Master Selector"
>> help
>> diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
>> index 9948fa4..a452d09 100644
>> --- a/drivers/i2c/muxes/Makefile
>> +++ b/drivers/i2c/muxes/Makefile
>> @@ -7,6 +7,7 @@ obj-$(CONFIG_I2C_DEMUX_PINCTRL) += i2c-demux-pinctrl.o
>>
>> obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
>> obj-$(CONFIG_I2C_MUX_MLXCPLD) += i2c-mux-mlxcpld.o
>> +obj-$(CONFIG_I2C_MUX_LTC4306) += i2c-mux-ltc4306.o
>
> Keep the list sorted, please.
>
>> obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
>> obj-$(CONFIG_I2C_MUX_PCA954x) += i2c-mux-pca954x.o
>> obj-$(CONFIG_I2C_MUX_PINCTRL) += i2c-mux-pinctrl.o
>> diff --git a/drivers/i2c/muxes/i2c-mux-ltc4306.c b/drivers/i2c/muxes/i2c-mux-ltc4306.c
>> new file mode 100644
>> index 0000000..f0fd4d1
>> --- /dev/null
>> +++ b/drivers/i2c/muxes/i2c-mux-ltc4306.c
>> @@ -0,0 +1,365 @@
>> +/*
>> + * Linear Technology LTC4306 and LTC4305 I2C multiplexer/switch
>> + *
>> + * Copyright (C) 2017 Analog Devices Inc.
>> + *
>> + * Licensed under the GPL-2.
>> + *
>> + * Based on: i2c-mux-pca954x.c
>> + *
>> + * Datasheet: http://cds.linear.com/docs/en/datasheet/4306.pdf
>> + */
>> +
>> +#include <linux/device.h>
>> +#include <linux/i2c.h>
>> +#include <linux/i2c-mux.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/gpio.h>
>> +#include <linux/gpio/driver.h>
>> +#include <linux/gpio/consumer.h>
>
> Sort the includes, please.
>
>> +
>> +#define LTC4306_MAX_NCHANS 4
>
> Why not a define for LTC4305_MAX_NCHANS as well?
>
>> +
>> +#define LTC_REG_STATUS 0x0
>> +#define LTC_REG_CONFIG 0x1
>> +#define LTC_REG_MODE 0x2
>> +#define LTC_REG_SWITCH 0x3
>> +
>> +#define LTC_DOWNSTREAM_ACCL_EN BIT(6)
>> +#define LTC_UPSTREAM_ACCL_EN BIT(7)
>> +
>> +#define LTC_GPIO_ALL_INPUT 0xC0
>> +
>> +enum ltc_type {
>> + ltc_4305,
>> + ltc_4306,
>> +};
>> +
>> +struct chip_desc {
>> + u8 nchans;
>> + u8 num_gpios;
>> +};
>> +
>> +struct ltc4306 {
>> + struct i2c_client *client;
>> + struct gpio_chip gpiochip;
>> + const struct chip_desc *chip;
>> +
>> + u8 deselect;
>> + u8 regs[LTC_REG_SWITCH + 1];
>
> Feels like a generic register cache, can you use regmap?
Regmap could do this and it may work. But to my knowledge it's not
recommended to mix regmap with direct smbus or direct adaptor transactions.
>
>> +};
>> +
>> +/* Provide specs for the PCA954x types we know about */
>> +static const struct chip_desc chips[] = {
>> + [ltc_4305] = {
>> + .nchans = 2,
>> + },
>> + [ltc_4306] = {
>> + .nchans = LTC4306_MAX_NCHANS,
>> + .num_gpios = 2,
>> + },
>> +};
>> +
>> +static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> + int ret = 0;
>> +
>> + if (gpiochip_line_is_open_drain(chip, offset) ||
>> + (data->regs[LTC_REG_MODE] & BIT(7 - offset))) {
>
> Alignment should match open parenthesis.
>
>> + /* Open Drain or Input */
>> + ret = i2c_smbus_read_byte_data(data->client, LTC_REG_CONFIG);
>> + if (ret < 0)
>> + return ret;
>> +
>> + return !!(ret & BIT(1 - offset));
>> + } else {
>> + return !!(data->regs[LTC_REG_CONFIG] & BIT(5 - offset));
>> + }
>> +}
>> +
>> +static void ltc4306_gpio_set(struct gpio_chip *chip, unsigned int offset,
>> + int value)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + if (value)
>> + data->regs[LTC_REG_CONFIG] |= BIT(5 - offset);
>> + else
>> + data->regs[LTC_REG_CONFIG] &= ~BIT(5 - offset);
>> +
>> +
>
> Please don't use multiple blank lines.
>
>> + i2c_smbus_write_byte_data(data->client, LTC_REG_CONFIG,
>> + data->regs[LTC_REG_CONFIG]);
>
> Alignment should match open parenthesis.
>
>> +}
>> +
>> +static int ltc4306_gpio_direction_input(struct gpio_chip *chip,
>> + unsigned int offset)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + data->regs[LTC_REG_MODE] |= BIT(7 - offset);
>> +
>> + return i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
>> + data->regs[LTC_REG_MODE]);
>> +}
>> +
>> +static int ltc4306_gpio_direction_output(struct gpio_chip *chip,
>> + unsigned int offset, int value)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + ltc4306_gpio_set(chip, offset, value);
>> + data->regs[LTC_REG_MODE] &= ~BIT(7 - offset);
>> +
>> + return i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
>> + data->regs[LTC_REG_MODE]);
>> +}
>> +
>> +static int ltc4306_gpio_set_config(struct gpio_chip *chip,
>> + unsigned int offset, unsigned long config)
>> +{
>> + struct ltc4306 *data = gpiochip_get_data(chip);
>> +
>> + switch (pinconf_to_config_param(config)) {
>> + case PIN_CONFIG_DRIVE_OPEN_DRAIN:
>> + data->regs[LTC_REG_MODE] &= ~BIT(4 - offset);
>> + break;
>> + case PIN_CONFIG_DRIVE_PUSH_PULL:
>> + data->regs[LTC_REG_MODE] |= BIT(4 - offset);
>> + break;
>> + default:
>> + return -ENOTSUPP;
>> + }
>> +
>> + return i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
>> + data->regs[LTC_REG_MODE]);
>> +}
>> +
>> +static int ltc4306_gpio_init(struct ltc4306 *data)
>> +{
>> + if (!data->chip->num_gpios)
>> + return 0;
>> +
>> + data->gpiochip.label = dev_name(&data->client->dev);
>> + data->gpiochip.base = -1;
>> + data->gpiochip.ngpio = data->chip->num_gpios;
>> + data->gpiochip.parent = &data->client->dev;
>> + data->gpiochip.can_sleep = true;
>> + data->gpiochip.direction_input = ltc4306_gpio_direction_input;
>> + data->gpiochip.direction_output = ltc4306_gpio_direction_output;
>> + data->gpiochip.get = ltc4306_gpio_get;
>> + data->gpiochip.set = ltc4306_gpio_set;
>> + data->gpiochip.set_config = ltc4306_gpio_set_config;
>> + data->gpiochip.owner = THIS_MODULE;
>> +
>> + /* gpiolib assumes all GPIOs default input */
>> + data->regs[LTC_REG_MODE] |= LTC_GPIO_ALL_INPUT;
>> + i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
>> + data->regs[LTC_REG_MODE]);
>
> Alignment should match open parenthesis.
>
>> +
>> + return devm_gpiochip_add_data(&data->client->dev,
>> + &data->gpiochip, data);
>> +}
>> +
>> +/*
>> + * Write to chip register. Don't use i2c_transfer()/i2c_smbus_xfer()
>> + * as they will try to lock the adapter a second time.
>> + */
>> +static int ltc4306_reg_write(struct i2c_adapter *adap,
>> + struct i2c_client *client, u8 reg, u8 val)
>> +{
>> + int ret;
>> +
>> + if (adap->algo->master_xfer) {
>> + struct i2c_msg msg;
>> + char buf[2];
>> +
>> + msg.addr = client->addr;
>> + msg.flags = 0;
>> + msg.len = 2;
>> + buf[0] = reg;
>> + buf[1] = val;
>> + msg.buf = buf;
>> + ret = __i2c_transfer(adap, &msg, 1);
>> + } else {
>> + union i2c_smbus_data data;
>> +
>> + data.byte = val;
>> + ret = adap->algo->smbus_xfer(adap, client->addr,
>> + client->flags,
>> + I2C_SMBUS_WRITE,
>> + reg,
>> + I2C_SMBUS_BYTE_DATA, &data);
>> + }
>> +
>> + return ret;
>> +}
>
> You have selected to go parent-locked, but you can get rid of the above
> workaround if you go mux-locked. See Documentation/i2c/i2c-topology for
> how these differ. Overall, since you do have the GPIO possibility, I think
> you are closing some possibilities by going parent-locked. Those GPIOs
> will more easily get locked out if you build a complex tree involving
> these muxes, when the mux is parent-locked.
>
> But on the other hand, mux-locked doesn't work everywhere either, the person
> who needs mux-locked can add that option if you don't want to...
For now we stay parent-locked.
>
>> +static int ltc4306_select_chan(struct i2c_mux_core *muxc, u32 chan)
>> +{
>> + struct ltc4306 *data = i2c_mux_priv(muxc);
>> + struct i2c_client *client = data->client;
>> + u8 regval;
>> + int ret = 0;
>> +
>> + regval = BIT(7 - chan);
>> +
>> + /* Only select the channel if its different from the last channel */
>> + if (data->regs[LTC_REG_SWITCH] != regval) {
>> + ret = ltc4306_reg_write(muxc->parent, client,
>> + LTC_REG_SWITCH, regval);
>> + data->regs[LTC_REG_SWITCH] = ret < 0 ? 0 : regval;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static int ltc4306_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
>> +{
>> + struct ltc4306 *data = i2c_mux_priv(muxc);
>> + struct i2c_client *client = data->client;
>> +
>> + if (!(data->deselect & BIT(chan)))
>> + return 0;
>> +
>> + /* Deselect active channel */
>> + data->regs[LTC_REG_SWITCH] = 0;
>> +
>> + return ltc4306_reg_write(muxc->parent, client,
>> + LTC_REG_SWITCH, data->regs[LTC_REG_SWITCH]);
>> +}
>> +
>> +static const struct i2c_device_id ltc4306_id[] = {
>> + { "ltc4305", ltc_4305 },
>> + { "ltc4306", ltc_4306 },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, ltc4306_id);
>> +
>> +static const struct of_device_id ltc4306_of_match[] = {
>> + { .compatible = "lltc,ltc4305", .data = &chips[ltc_4305] },
>> + { .compatible = "lltc,ltc4306", .data = &chips[ltc_4306] },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, ltc4306_of_match);
>> +
>> +static int ltc4306_probe(struct i2c_client *client,
>> + const struct i2c_device_id *id)
>> +{
>> + struct i2c_adapter *adap = to_i2c_adapter(client->dev.parent);
>> + struct device_node *of_node = client->dev.of_node;
>> + bool idle_disconnect_dt = false;
>> + struct gpio_desc *gpio;
>> + struct i2c_mux_core *muxc;
>> + struct ltc4306 *data;
>> + const struct of_device_id *match;
>> + int num, ret;
>> +
>> + if (!i2c_check_functionality(adap, I2C_FUNC_SMBUS_BYTE_DATA))
>> + return -ENODEV;
>> +
>> + muxc = i2c_mux_alloc(adap, &client->dev,
>> + LTC4306_MAX_NCHANS, sizeof(*data), 0,
>> + ltc4306_select_chan, ltc4306_deselect_mux);
>
> Where's the symmetry in ..._chan for select and ..._mux for deselect?
>
>> + if (!muxc)
>> + return -ENOMEM;
>> + data = i2c_mux_priv(muxc);
>> +
>> + i2c_set_clientdata(client, muxc);
>> + data->client = client;
>> +
>> + /* Enable the mux if a enable GPIO is specified. */
>
> s/ a / an /
>
>> + gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_HIGH);
>> + if (IS_ERR(gpio))
>> + return PTR_ERR(gpio);
>
> Should you not use this pin later as well? In suspend/resume if you add
> handling for that?
My assumption was that freed GPIOs return to input.
This doesn't seem to be the case. I'll configure the enable GPIO to
INPUT on error and removal. This way an external PULL-UP or PULL-DOWN
defines the expected behavior, since a HIGH->LOW transition may also
reset the chip.
>
>> +
>> + /* Write the mux register at addr to verify
>> + * that the mux is in fact present. This also
>> + * initializes the mux to disconnected state.
>> + */
>
> Multi-line comments should start with a /* on its own line.
>
>> + if (i2c_smbus_write_byte_data(client, LTC_REG_SWITCH, 0) < 0) {
>> + dev_warn(&client->dev, "probe failed\n");
>> + return -ENODEV;
>> + }
>> +
>> + match = of_match_device(of_match_ptr(ltc4306_of_match), &client->dev);
>
> Just call of_device_get_match_data() directly.
I'll move of_device_get_match_data() into the of_node clause below.
>
>> + if (match)
>> + data->chip = of_device_get_match_data(&client->dev);
>> + else
>> + data->chip = &chips[id->driver_data];
>> +
>> + if (of_node) {
>> + idle_disconnect_dt =
>> + of_property_read_bool(of_node,
>> + "i2c-mux-idle-disconnect");
>> + if (of_property_read_bool(of_node,
>> + "ltc,downstream-accelerators-enable"))
>> + data->regs[LTC_REG_CONFIG] |= LTC_DOWNSTREAM_ACCL_EN;
>> +
>> + if (of_property_read_bool(of_node,
>> + "ltc,upstream-accelerators-enable"))
>> + data->regs[LTC_REG_CONFIG] |= LTC_UPSTREAM_ACCL_EN;
>> +
>> + if (i2c_smbus_write_byte_data(client, LTC_REG_CONFIG,
>> + data->regs[LTC_REG_CONFIG]) < 0) {
>> + dev_warn(&client->dev, "probe failed\n");
>> + return -ENODEV;
>> + }
>> + }
>> +
>> + ret = ltc4306_gpio_init(data);
>> + if (ret < 0)
>> + return ret;
>> +
>> + /* Now create an adapter for each channel */
>> + for (num = 0; num < data->chip->nchans; num++) {
>> +
>
> Blank lines aren't necessary after an open brace.
>
>> + data->deselect |= idle_disconnect_dt << num;
>
> Either *all* relevant bits are 1 or *all* relevant bits are 0. You
> can get rid of this variable and invoke i2c_mux_alloc with NULL
> instead of ltc4306_deselect_mux when not configured to disconnect
> the mux. You have to delay the mux allocation to later in probe,
> but I don't think it will be too hairy to accomplish that?
Yeah - that's easy.
--
Greetings,
Michael
--
Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne
^ permalink raw reply
* Re: [PATCH] drm: rcar-du: Document the vsps property in the DT bindings
From: Geert Uytterhoeven @ 2017-03-27 11:05 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Linux-Renesas, devicetree@vger.kernel.org, DRI Development,
Sergei Shtylyov
In-Reply-To: <20170327095652.5755-1-laurent.pinchart+renesas@ideasonboard.com>
Hi Laurent,
On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart
<laurent.pinchart+renesas@ideasonboard.com> wrote:
> The property is used by the driver but is missing from the DT bindings.
> Document it.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Documentation/devicetree/bindings/display/renesas,du.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt
> index 1a02f099a0ff..cf34893a1b53 100644
> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -36,6 +36,11 @@ Required Properties:
> When supplied they must be named "dclkin.x" with "x" being the input
> clock numerical index.
>
> +Optional Properties:
> +
> + - vsps: A list of phandles to the VSP nodes that handle the memory
> + interfaces for the DU channels (Gen3 only).
", one per channel"?
Required for Gen3, optional for Gen2? (cfr. Sergei's patches).
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v5 00/13] ACPI graph support
From: Mika Westerberg @ 2017-03-27 11:03 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, sudeep.holla-5wv7dgnIgG8,
lorenzo.pieralisi-5wv7dgnIgG8, rafael-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, broonie-DgEjT+Ai2ygdnm+yROfE0A,
robh-DgEjT+Ai2ygdnm+yROfE0A, ahs3-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <0b9104c2-4a3a-47db-ff1d-8f835fe3b567-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Mon, Mar 27, 2017 at 12:17:50AM +0300, Sakari Ailus wrote:
> Could you also review the other related patches? There are just a few and
> they're relatively simple:
>
> Set of three patches (which precedes what you reviewed):
>
> <URL:http://www.spinics.net/lists/linux-acpi/msg72895.html>
>
> And then finally:
>
> <URL:http://www.spinics.net/lists/linux-acpi/msg72888.html>
Sure, I'll go ahead and check those now.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 5/7] clk: tegra: don't warn for PLL defaults unnecessarily
From: Jon Hunter @ 2017-03-27 11:02 UTC (permalink / raw)
To: Peter De Schrijver, Prashant Gaikwad, Michael Turquette,
Stephen Boyd, Stephen Warren, Thierry Reding, Alexandre Courbot,
Rob Herring, Mark Rutland, Rhyland Klein,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1487846686-6388-6-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Hi Peter,
On 23/02/17 10:44, Peter De Schrijver wrote:
> If the PLL is on, only warn if the defaults are not yet set. Otherwise be
> silent.
>
> Signed-off-by: Peter De Schrijver <pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/clk/tegra/clk-tegra210.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
> index b7ef8a7..fe698d2 100644
> --- a/drivers/clk/tegra/clk-tegra210.c
> +++ b/drivers/clk/tegra/clk-tegra210.c
> @@ -502,7 +502,7 @@ static void tegra210_pllcx_set_defaults(const char *name,
> pllcx->params->defaults_set = true;
>
> if (readl_relaxed(clk_base + pllcx->params->base_reg) &
> - PLL_ENABLE) {
> + PLL_ENABLE && !pllcx->params->defaults_set) {
> /* PLL is ON: only check if defaults already set */
> pllcx_check_defaults(pllcx->params);
> pr_warn("%s already enabled. Postponing set full defaults\n",
The above hunk is causing the Tegra210 Smaug boot to fail. Looking more
at the code, I believe that the above hunk is not correct, because
'defaults_set' is always true and this is now causing us to always reset
the PLL if in-use or not. I will send a patch to correct this.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCHv3 2/2] drm/panel: simple: Add support for Winstar WF35LTIACD
From: Richard Genoud @ 2017-03-27 10:33 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, Mark Rutland,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Richard Genoud
This adds support for the Winstar Display Co. WF35LTIACD 3.5" QVGA TFT
LCD panel, which can be supported by the simple panel driver.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Changes since v2:
Remove status, reg and unit-addresses from example
Changes since v1:
Add power-supply property and an example in documentation
.../bindings/display/panel/winstar,wf35ltiacd | 48 ++++++++++++++++++++++
drivers/gpu/drm/panel/panel-simple.c | 28 +++++++++++++
2 files changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
diff --git a/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd b/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
new file mode 100644
index 000000000000..2a7e6e3ba64c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
@@ -0,0 +1,48 @@
+Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
+
+Required properties:
+- compatible: should be "winstar,wf35ltiacd"
+- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Example:
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&hlcdc_pwm 0 50000 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 31 63 95 127 159 191 223 255>;
+ default-brightness-level = <191>;
+ power-supply = <&bl_reg>;
+ };
+
+ bl_reg: backlight_regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "backlight-power-supply";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ panel: panel {
+ compatible = "winstar,wf35ltiacd", "simple-panel";
+ backlight = <&backlight>;
+ power-supply = <&panel_reg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint {
+ remote-endpoint = <&hlcdc_panel_output>;
+ };
+ };
+ };
+
+ panel_reg: panel_regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-power-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79de8c8..5d45664c6c0e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1713,6 +1713,31 @@ static const struct panel_desc urt_umsh_8596md_parallel = {
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct drm_display_mode winstar_wf35ltiacd_mode = {
+ .clock = 6410,
+ .hdisplay = 320,
+ .hsync_start = 320 + 20,
+ .hsync_end = 320 + 20 + 30,
+ .htotal = 320 + 20 + 30 + 38,
+ .vdisplay = 240,
+ .vsync_start = 240 + 4,
+ .vsync_end = 240 + 4 + 3,
+ .vtotal = 240 + 4 + 3 + 15,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc winstar_wf35ltiacd = {
+ .modes = &winstar_wf35ltiacd_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 70,
+ .height = 53,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am800480r3tmqwa1h",
@@ -1892,6 +1917,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "urt,umsh-8596md-20t",
.data = &urt_umsh_8596md_parallel,
}, {
+ .compatible = "winstar,wf35ltiacd",
+ .data = &winstar_wf35ltiacd,
+ }, {
/* sentinel */
}
};
--
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 2/8] pinctrl: stm32: use gpio-ranges to declare bank range
From: Alexandre Torgue @ 2017-03-27 10:23 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland, devicetree@vger.kernel.org, Arnd Bergmann,
linux-kernel@vger.kernel.org, Russell King, Patrice Chotard,
linux-gpio@vger.kernel.org, Rob Herring, Maxime Coquelin,
Olof Johansson, Lee Jones, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACRpkdbhqT688-1MajRshqgn0bH0h2s=LM06gEQYgRmMZC_n0g@mail.gmail.com>
Hi Linus
On 02/01/2017 04:01 PM, Linus Walleij wrote:
> On Mon, Jan 30, 2017 at 5:29 PM, Alexandre Torgue
> <alexandre.torgue@st.com> wrote:
>> On 01/30/2017 04:19 PM, Linus Walleij wrote:
>
>>>> + if (!of_parse_phandle_with_fixed_args(np, "gpio-ranges", 3, 0,
>>>> &args))
>>>> + bank_nr = args.args[1] / STM32_GPIO_PINS_PER_BANK;
>>>> + else {
>>>> + range->name = bank->gpio_chip.label;
>>>> + range->id = bank_nr;
>>>> + range->pin_base = range->id * STM32_GPIO_PINS_PER_BANK;
>>>> + range->base = range->id * STM32_GPIO_PINS_PER_BANK;
>>>> + range->npins = npins;
>>>> + range->gc = &bank->gpio_chip;
>>>> + pinctrl_add_gpio_range(pctl->pctl_dev,
>>>> + &pctl->banks[bank_nr].range);
>>>> + }
>>
>>
>> I Keep the old way to get range in order to keep compatibility with older
>> device tree (if no gpio ranges are defined).
>
> Aha I understand. Sorry for my stupidity.
>
> Go ahead with this!
I saw an issue about this patch. It doesn't seem to be merged, so I will
send a V2 only for this patch.
Regards
Alex
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* RE: [RESEND PATCH V5 7/8] thermal: da9062/61: Thermal junction temperature monitoring driver
From: Steve Twiss @ 2017-03-27 10:09 UTC (permalink / raw)
To: Eduardo Valentin
Cc: LINUX-KERNEL, LINUX-PM, Zhang Rui, DEVICETREE, Dmitry Torokhov,
Guenter Roeck, LINUX-INPUT, LINUX-WATCHDOG, Lee Jones,
Liam Girdwood, Lukasz Luba, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck
In-Reply-To: <20170219014007.GA20845-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On 19 February 2017 01:40, Eduardo Valentin wrote:
Hi Eduardo,
My apologies in taking so long to reply.
There were *no* problems with implementing your requests. See below.
I will have sent these changes as PATCH V6.
https://lkml.org/lkml/2017/3/27/253
Regards,
Steve
> To: Steve Twiss
> Subject: Re: [RESEND PATCH V5 7/8] thermal: da9062/61: Thermal junction
> temperature monitoring driver
[...]
> I see no reason why this driver cannot have the COMPILE_TEST flag.
> Tested myself here so:
>
> + depends on MFD_DA9062 || COMPILE_TEST
Added.
> please cleanup the minor issues checkpatch complains:
> /scripts/checkpatch.pl --strict <your patch>
I have fixed all of those for latest checkpatch.pl script, this time using "--strict".
[...]
> > +static void da9062_thermal_poll_on(struct work_struct *work)
> > +{
> > + struct da9062_thermal *thermal = container_of(work,
> > + struct da9062_thermal,
> > + work.work);
> > + unsigned int val;
> > + int ret;
> > +
> > + /* clear E_TEMP */
> > + ret = regmap_write(thermal->hw->regmap,
> > + DA9062AA_EVENT_B,
> > + DA9062AA_E_TEMP_MASK);
> > + if (ret < 0) {
> > + dev_err(thermal->dev,
> > + "Cannot clear the TJUNC temperature status\n");
> > + goto err_enable_irq;
> > + }
> > +
> > + /* Now read E_TEMP again: it is acting like a status bit.
> > + * If over-temperature, then this status will be true.
> > + * If not over-temperature, this status will be false.
> > + */
> > + ret = regmap_read(thermal->hw->regmap,
> > + DA9062AA_EVENT_B,
> > + &val);
> > + if (ret < 0) {
> > + dev_err(thermal->dev,
> > + "Cannot check the TJUNC temperature status\n");
> > + goto err_enable_irq;
> > + } else {
> > + if (val & DA9062AA_E_TEMP_MASK) {
> > + mutex_lock(&thermal->lock);
> > + thermal->temperature = DA9062_MILLI_CELSIUS(125);
> > + mutex_unlock(&thermal->lock);
> > + thermal_zone_device_update(thermal->zone,
> > + THERMAL_EVENT_UNSPECIFIED);
> > +
> > + schedule_delayed_work(&thermal->work,
> > + msecs_to_jiffies(thermal->zone->passive_delay));
> > + return;
> > + } else {
> > + mutex_lock(&thermal->lock);
> > + thermal->temperature = DA9062_MILLI_CELSIUS(0);
> > + mutex_unlock(&thermal->lock);
> > + thermal_zone_device_update(thermal->zone,
> > + THERMAL_EVENT_UNSPECIFIED);
> > + }
> > + }
>
> The above code is a little confusing, can it be maybe, better read like
> this?
>
> diff --git a/drivers/thermal/da9062-thermal.c b/drivers/thermal/da9062-
> thermal.c
> index 52a095d..6ac8574 100644
> --- a/drivers/thermal/da9062-thermal.c
> +++ b/drivers/thermal/da9062-thermal.c
> @@ -95,26 +95,26 @@ static void da9062_thermal_poll_on(struct work_struct
> *work)
> dev_err(thermal->dev,
> "Cannot check the TJUNC temperature status\n");
> goto err_enable_irq;
> - } else {
> - if (val & DA9062AA_E_TEMP_MASK) {
> - mutex_lock(&thermal->lock);
> - thermal->temperature = DA9062_MILLI_CELSIUS(125);
> - mutex_unlock(&thermal->lock);
> - thermal_zone_device_update(thermal->zone,
> - THERMAL_EVENT_UNSPECIFIED);
> -
> - schedule_delayed_work(&thermal->work,
> + }
> +
> + if (val & DA9062AA_E_TEMP_MASK) {
> + mutex_lock(&thermal->lock);
> + thermal->temperature = DA9062_MILLI_CELSIUS(125);
> + mutex_unlock(&thermal->lock);
> + thermal_zone_device_update(thermal->zone,
> + THERMAL_EVENT_UNSPECIFIED);
> +
> + schedule_delayed_work(&thermal->work,
> msecs_to_jiffies(thermal->zone->passive_delay));
> - return;
> - } else {
> - mutex_lock(&thermal->lock);
> - thermal->temperature = DA9062_MILLI_CELSIUS(0);
> - mutex_unlock(&thermal->lock);
> - thermal_zone_device_update(thermal->zone,
> - THERMAL_EVENT_UNSPECIFIED);
> - }
> + return;
> }
>
> + mutex_lock(&thermal->lock);
> + thermal->temperature = DA9062_MILLI_CELSIUS(0);
> + mutex_unlock(&thermal->lock);
> + thermal_zone_device_update(thermal->zone,
> + THERMAL_EVENT_UNSPECIFIED);
> +
> err_enable_irq:
> enable_irq(thermal->irq);
> }
That makes more sense getting rid of those else clauses.
Applied that, thanks.
Regards,
Steve
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: Document the STM32 MDMA bindings
From: M'boumba Cedric Madianga @ 2017-03-27 10:06 UTC (permalink / raw)
To: Rob Herring
Cc: Vinod Koul, Mark Rutland, Maxime Coquelin, Alexandre Torgue,
Dan Williams, dmaengine, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20170320215250.wwhq6lzwe45jmwks@rob-hp-laptop>
Hi Rob,
2017-03-20 22:52 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Mon, Mar 13, 2017 at 04:06:38PM +0100, M'boumba Cedric Madianga wrote:
>> This patch adds documentation of device tree bindings for the STM32 MDMA
>> controller.
>>
>> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
>> Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
>> ---
>> .../devicetree/bindings/dma/stm32-mdma.txt | 94 ++++++++++++++++++++++
>> 1 file changed, 94 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/dma/stm32-mdma.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/stm32-mdma.txt b/Documentation/devicetree/bindings/dma/stm32-mdma.txt
>> new file mode 100644
>> index 0000000..26a930c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/stm32-mdma.txt
>> @@ -0,0 +1,94 @@
>> +* STMicroelectronics STM32 MDMA controller
>> +
>> +The STM32 MDMA is a general-purpose direct memory access controller capable of
>> +supporting 64 independent DMA channels with 256 HW requests.
>> +
>> +Required properties:
>> +- compatible: Should be "st,stm32-mdma"
>
> Should be more specific.
The compatible string is not specific enough ? I don't see how to specific more.
>
>> +- reg: Should contain MDMA registers location and length. This should include
>> + all of the per-channel registers.
>> +- interrupts: Should contain the MDMA interrupt.
>> +- clocks: Should contain the input clock of the DMA instance.
>> +- resets: Reference to a reset controller asserting the DMA controller.
>> +- #dma-cells : Must be <5>. See DMA client paragraph for more details.
>> +
>> +Optional properties:
>> +- dma-channels: Number of DMA channels supported by the controller.
>> +- dma-requests: Number of DMA request signals supported by the controller.
>> +- st,ahb-addr-masks: Array of u32 mask to list memory devices addressed via
>> + AHB bus.
>
> I don't understand what this is.
The MDMA is able to address memories and devices from AHB bus or AXI bus.
The MDMA has a little different way of working to address AHB
device/memory and AXI device/memory.
In STM32H7 platform, almost all devices are addressed by AXI bus.
But we have some memories adress by AHB bus.
So, we add these parameter to be able to handle this.
>
>> +
>> +Example:
>
> Put the 2 examples together.
OK
>
>> +
>> + mdma1: dma@52000000 {
>> + compatible = "st,stm32-mdma";
>> + reg = <0x52000000 0x1000>;
>> + interrupts = <122>;
>> + clocks = <&clk_dummy>;
>> + resets = <&rcc 992>;
>> + #dma-cells = <5>;
>> + dma-channels = <16>;
>> + dma-requests = <32>;
>> + st,ahb-addr-masks = <0x20000000>, <0x00000000>;
>> + };
>> +
>> +* DMA client
>> +
>> +DMA clients connected to the STM32 MDMA controller must use the format
>> +described in the dma.txt file, using a six-cell specifier for each channel:
>> +a phandle to the MDMA controller plus the following five integer cells:
>> +
>> +1. The request line number
>> +2. The priority level
>> + 0x00: Low
>> + 0x01: Medium
>> + 0x10: High
>> + 0x11: Very high
>> +3. A 32bit mask specifying the DMA channel configuration
>> + -bit 0-1: Source increment mode
>> + 0x00: Source address pointer is fixed
>> + 0x10: Source address pointer is incremented after each data transfer
>> + 0x11: Source address pointer is decremented after each data transfer
>> + -bit 2-3: Destination increment mode
>> + 0x00: Destination address pointer is fixed
>> + 0x10: Destination address pointer is incremented after each data
>> + transfer
>> + 0x11: Destination address pointer is decremented after each data
>> + transfer
>> + -bit 8-9: Source increment offset size
>> + 0x00: byte (8bit)
>> + 0x01: half-word (16bit)
>> + 0x10: word (32bit)
>> + 0x11: double-word (64bit)
>> + -bit 10-11: Destination increment offset size
>> + 0x00: byte (8bit)
>> + 0x01: half-word (16bit)
>> + 0x10: word (32bit)
>> + 0x11: double-word (64bit)
>> +-bit 25-18: The number of bytes to be transferred in a single transfer
>> + (min = 1 byte, max = 128 bytes)
>> +-bit 29:28: Trigger Mode
>> + 0x00: Each MDMA request triggers a buffer transfer (max 128 bytes)
>> + 0x01: Each MDMA request triggers a block transfer (max 64K bytes)
>> + 0x10: Each MDMA request triggers a repeated block transfer
>> + 0x11: Each MDMA request triggers a linked list transfer
>> +4. A 32bit value specifying the register to be used to acknowledge the request
>> + if no HW ack signal is used by the MDMA client
>> +5. A 32bit mask specifying the value to be written to acknowledge the request
>> + if no HW ack signal is used by the MDMA client
>> +
>> +Example:
>> +
>> + i2c4: i2c@5c002000 {
>> + compatible = "st,stm32f7-i2c";
>> + reg = <0x5c002000 0x400>;
>> + interrupts = <GIC_SPI 95 IRQ_TYPE_NONE>,
>> + <GIC_SPI 96 IRQ_TYPE_NONE>;
>> + clocks = <&clk_hsi>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + dmas = <&mdma1 36 0x0 0x40008 0x0 0x0>,
>> + <&mdma1 37 0x0 0x40002 0x0 0x0>;
>> + dma-names = "rx", "tx";
>> + status = "disabled";
>> + };
>> --
>> 1.9.1
>>
^ permalink raw reply
* Re: [PATCH v5 0/8] Add dual-role OTG support for Allwinner H3
From: Kishon Vijay Abraham I @ 2017-03-27 10:05 UTC (permalink / raw)
To: Icenowy Zheng, Rob Herring, Maxime Ripard, Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170325145015.22076-1-icenowy-ymACFijhrKM@public.gmane.org>
On Saturday 25 March 2017 08:20 PM, Icenowy Zheng wrote:
> Allwinner H3 have a its USB PHY0 routed to two USB controllers: one is
> a MUSB controller, which can work in peripheral mode, but works badly in
> host mode (several hardware will fail on the MUSB controller, even connect
> one MUSB controller in peripheral mode to another one in host mode cannot
> work); the other is a pair of EHCI/OHCI controller, which can work only
> in host mode, but have better compatibillity. The route is controlled in
> a register, which we have set it to HCI only when we do not know about
> it well.
>
> Add support to route to the best controller according to current USB mode
> (host/peripheral).
>
> Note: Currently even if hardware only support hostmode, we should still
> enable the MUSB controller, as it controls the USB mode. (Some this kind
> of hardware can also work in peripheral mode by settings in the sysfs
> node of MUSB, then connect it to another host via a USB Type-A to Type-A
> cable.)
>
> Patch 1 changes the device tree binding to include the "pmu0" for HCI pair.
>
> Patch 2 and 3 are fixes for H3 PHY, in order to make MUSB really working
> on H3.
>
> Patch 4 adds support for auto routing of PHY0. It's currently only enabled
> on H3, but it's easy to extend it to other SoCs which feature this
> route control.
merged the 1st four patch of this series.
Thanks
Kishon
>
> Patch 5 adds necessary device tree nodes to the H3/H5 DTSI file. Note: The
> phy is not bind for OHCI/EHCI0, as OHCI/EHCI drivers will keep the VBUS
> on. Only MUSB driver can properly handle a dual-role PHY.
>
> Patch 6 enables USB OTG functionality on Orange Pi One board, which is
> the only H3 board I have that have proper OTG function. It's easy to
> enable OTG on other boards with their schematics.
>
> Patch 7 enables USB OTG functionality on Orange Pi Zero board, as the
> board cannot output power on Vbus, I only enabled peripheral mode by
> default.
>
> Patch 8 enables USB OTG funcionality on Orange Pi PC2 board, which is
> the newly support H5 board, and have USB-related pins same as Orange
> Pi One.
>
> The USB PHY on V3s/A64 SoCs also feature this capability, and it will
> be soon enabled on these SoCs after this patchset is merged.
>
> Icenowy Zheng (8):
> dt: bindings: add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64
> phy: sun4i-usb: change PHYCTL register clearing code
> phy: sun4i-usb: add PHYCTL offset for H3 SoC
> phy: sun4i-usb: support automatically switch PHY0 route to MUSB/HCI
> ARM: sunxi: h3/h5: add usb_otg and OHCI/EHCI for usbc0 on H3/H5
> ARM: sun8i: h3: enable USB OTG on Orange Pi One
> ARM: sun8i: h2+: enable USB OTG for Orange Pi Zero board
> arm64: allwinner: h5: enable USB OTG on Orange Pi PC 2 board
>
> .../devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
> arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 20 +++++++-
> arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 22 ++++++++-
> arch/arm/boot/dts/sunxi-h3-h5.dtsi | 32 ++++++++++++
> .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 27 +++++++++-
> drivers/phy/phy-sun4i-usb.c | 57 ++++++++++++++--------
> 6 files changed, 135 insertions(+), 24 deletions(-)
>
^ permalink raw reply
* [PATCH] drm: rcar-du: Document the vsps property in the DT bindings
From: Laurent Pinchart @ 2017-03-27 9:56 UTC (permalink / raw)
To: devicetree; +Cc: linux-renesas-soc, dri-devel
The property is used by the driver but is missing from the DT bindings.
Document it.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
Documentation/devicetree/bindings/display/renesas,du.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt
index 1a02f099a0ff..cf34893a1b53 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -36,6 +36,11 @@ Required Properties:
When supplied they must be named "dclkin.x" with "x" being the input
clock numerical index.
+Optional Properties:
+
+ - vsps: A list of phandles to the VSP nodes that handle the memory
+ interfaces for the DU channels (Gen3 only).
+
Required nodes:
The connections to the DU output video ports are modeled using the OF graph
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH V6 7/7] MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search terms
From: Steve Twiss @ 2017-03-27 9:51 UTC (permalink / raw)
To: Dmitry Torokhov, Eduardo Valentin, Guenter Roeck, Mark Rutland,
Rob Herring, Wim Van Sebroeck, Zhang Rui
Cc: DEVICETREE, LINUX-INPUT, LINUX-KERNEL, LINUX-PM, LINUX-WATCHDOG,
Lee Jones, Liam Girdwood, Mark Brown, Support Opensource
In-Reply-To: <cover.1490608293.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
Hi,
Dialog Semiconductor support would like to add to the MAINTAINERS search
terms. This update will allow us to follow files for device tree bindings
and source code relating to input onkey drivers, chip thermal monitoring
and watchdog timers.
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.11-rc3
v5 -> v6
- NO CODE CHANGE
- Rebased from v4.8 to v4.11-rc3
- Patch renamed from [PATCH V5 8/8] to [PATCH V5 7/7]
v4 -> v5
- NO CODE CHANGE
- Rebased from v4.8 to v4.9
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 9/9] to [PATCH V4 8/8]
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 10/10] to [PATCH V3 9/9]
v1 -> v2
- NO CODE CHANGE
Hi,
This patch depends on acceptance of the following from this patch set:
- [PATCH V5 7/8] PMIC temperature monitoring
and also from the following binding file changes:
- Binding for onkey (already applied by Dmitry Torokhov)
- [PATCH V5 1/8] Binding for watchdog
- [PATCH V5 2/8] Binding for thermal
Regards,
Steve Twiss, Dialog Semiconductor
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c776906..bab1e77 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3926,7 +3926,10 @@ W: http://www.dialog-semiconductor.com/products
S: Supported
F: Documentation/hwmon/da90??
F: Documentation/devicetree/bindings/mfd/da90*.txt
+F: Documentation/devicetree/bindings/input/da90??-onkey.txt
+F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt
F: Documentation/devicetree/bindings/regulator/da92*.txt
+F: Documentation/devicetree/bindings/watchdog/da92??-wdt.txt
F: Documentation/devicetree/bindings/sound/da[79]*.txt
F: drivers/gpio/gpio-da90??.c
F: drivers/hwmon/da90??-hwmon.c
@@ -3941,6 +3944,7 @@ F: drivers/power/supply/da9052-battery.c
F: drivers/power/supply/da91??-*.c
F: drivers/regulator/da903x.c
F: drivers/regulator/da9???-regulator.[ch]
+F: drivers/thermal/da90??-thermal.c
F: drivers/rtc/rtc-da90??.c
F: drivers/video/backlight/da90??_bl.c
F: drivers/watchdog/da90??_wdt.c
--
end-of-patch for PATCH V6
^ permalink raw reply related
* [PATCH V6 6/7] thermal: da9062/61: Thermal junction temperature monitoring driver
From: Steve Twiss @ 2017-03-27 9:51 UTC (permalink / raw)
To: Eduardo Valentin, LINUX-KERNEL, LINUX-PM, Zhang Rui
Cc: DEVICETREE, Dmitry Torokhov, Guenter Roeck, LINUX-INPUT,
LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Lukasz Luba, Mark Brown,
Mark Rutland, Rob Herring, Support Opensource, Wim Van Sebroeck
In-Reply-To: <cover.1490608293.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
Add junction temperature monitoring supervisor device driver, compatible
with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added.
If the PMIC's internal junction temperature rises above T_WARN (125 degC)
an interrupt is issued. This T_WARN level is defined as the
THERMAL_TRIP_HOT trip-wire inside the device driver.
The thermal triggering mechanism is interrupt based and happens when the
temperature rises above a given threshold level. The component cannot
return an exact temperature, it only has knowledge if the temperature is
above or below a given threshold value. A status bit must be polled to
detect when the temperature falls below that threshold level again. A
kernel work queue is configured to repeatedly poll and detect when the
temperature falls below this trip-wire, between 1 and 10 second intervals
(defaulting at 3 seconds).
This scheme is provided as an example. It would be expected that any
final implementation will also include a notify() function and any of these
settings could be altered to match the application where appropriate.
When over-temperature is reached, the interrupt from the DA9061/2 will be
repeatedly triggered. The IRQ is therefore disabled when the first
over-temperature event happens and the status bit is polled using a
work-queue until it becomes false.
This strategy is designed to allow the periodic transmission of uevents
(HOT trip point) as the first level of temperature supervision method. It
is intended for non-invasive temperature control, where the necessary
measures for cooling the system down are left to the host software. Once
the temperature falls again, the IRQ is re-enabled so a new critical
over-temperature event can be detected.
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.11-rc3
v5 -> v6
- Patch renamed from [PATCH V5 7/8] to [PATCH V6 6/7]
- Rebased from v4.9 to v4.11-rc3
- Modify Copyright to match Dialog latest legal statement
- Various checkpatch warnings (from --strict) have been fixed
- Added COMPILE_TEST to Kconfig
v4 -> v5
- Rebased from v4.8 to v4.9
- Updates from comments by Eduardo Valentin
- Replace vendor defined dlg,tjunc-temp-polling-period-ms with standard
thermal core polling-delay-passive as part of the device tree
initialisation
- Change to the commit message content and device driver source code to
include an explanation of the repeated uevent strategy for monitoring
over-temperature
- Rename warning threshold name from TEMP_WARN to T_WARN to match the
latest datasheet naming convention
- Added reviewed-by Lukasz Luba to commit message
v3 -> v4
- Patch renamed from [PATCH V3 8/9] to [PATCH V4 7/8]
- Reordering of cancel_delayed_work_sync() in remove function
- dev_warn() message for out-of-range polling period requests
- Explanatory comment for expected values defined for
DEFAULT_POLLING_MS_PERIOD, MAX_POLLING_MS_PERIOD and
MIN_POLLING_MS_PERIOD
v2 -> v3
- Patch renamed from [PATCH V2 09/10] to [PATCH V3 8/9]
- Addition of MODULE_DEVICE_TABLE macro to allow modinfo additions
v1 -> v2
- Patch renamed from [PATCH V1 05/10] to [PATCH V2 09/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- List the header files in alphabetical order
- Remove "GPL v2" and replace with MODULE_LICENSE("GPL") to match the
copyright "GNU Public License v2 or later" option in the header
comment for this file. See the allowed identifiers in the file
include/linux/module.h +170
- Remove notify function "da9062_thermal_notify" function.
- MODULE_AUTHOR() macros removes Company Name and just gives Name in
accordance with include/linux/module.h +200
- Remove the compatible "dlg,da9061-thermal" option in the of_device_id
struct table. This patch now assumes the use of a DA9062 fallback
compatible string in the DTS when using the DA9061 thermal component
of the DA9061 device.
- Re-ordered some assignments earlier in the probe() for thermal->hw,
thermal->polling_period, thermal->mode, thermal->dev
- Added further information in the patch description to explain the use
of the device driver's built-in work-queue.
Regards,
Steve Twiss, Dialog Semiconductor
drivers/thermal/Kconfig | 10 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/da9062-thermal.c | 315 +++++++++++++++++++++++++++++++++++++++
3 files changed, 326 insertions(+)
create mode 100644 drivers/thermal/da9062-thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 776b3439..a784b02 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -303,6 +303,16 @@ config DB8500_CPUFREQ_COOLING
bound cpufreq cooling device turns active to set CPU frequency low to
cool down the CPU.
+config DA9062_THERMAL
+ tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
+ depends on MFD_DA9062 || COMPILE_TEST
+ depends on OF
+ help
+ Enable this for the Dialog Semiconductor thermal sensor driver.
+ This will report PMIC junction over-temperature for one thermal trip
+ zone.
+ Compatible with the DA9062 and DA9061 PMICs.
+
config INTEL_POWERCLAMP
tristate "Intel PowerClamp idle injection driver"
depends on THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 7adae20..297849e 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
obj-$(CONFIG_QORIQ_THERMAL) += qoriq_thermal.o
obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
+obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
obj-$(CONFIG_INTEL_SOC_DTS_IOSF_CORE) += intel_soc_dts_iosf.o
diff --git a/drivers/thermal/da9062-thermal.c b/drivers/thermal/da9062-thermal.c
new file mode 100644
index 0000000..dd8dd94
--- /dev/null
+++ b/drivers/thermal/da9062-thermal.c
@@ -0,0 +1,315 @@
+/*
+ * Thermal device driver for DA9062 and DA9061
+ * Copyright (C) 2017 Dialog Semiconductor
+ *
+ * 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.
+ */
+
+/* When over-temperature is reached, an interrupt from the device will be
+ * triggered. Following this event the interrupt will be disabled and
+ * periodic transmission of uevents (HOT trip point) should define the
+ * first level of temperature supervision. It is expected that any final
+ * implementation of the thermal driver will include a .notify() function
+ * to implement these uevents to userspace.
+ *
+ * These uevents are intended to indicate non-invasive temperature control
+ * of the system, where the necessary measures for cooling are the
+ * responsibility of the host software. Once the temperature falls again,
+ * the IRQ is re-enabled so the start of a new over-temperature event can
+ * be detected without constant software monitoring.
+ */
+
+#include <linux/errno.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/thermal.h>
+#include <linux/workqueue.h>
+
+#include <linux/mfd/da9062/core.h>
+#include <linux/mfd/da9062/registers.h>
+
+/* Minimum, maximum and default polling millisecond periods are provided
+ * here as an example. It is expected that any final implementation to also
+ * include a modification of these settings to match the required
+ * application.
+ */
+#define DA9062_DEFAULT_POLLING_MS_PERIOD 3000
+#define DA9062_MAX_POLLING_MS_PERIOD 10000
+#define DA9062_MIN_POLLING_MS_PERIOD 1000
+
+#define DA9062_MILLI_CELSIUS(t) ((t) * 1000)
+
+struct da9062_thermal_config {
+ const char *name;
+};
+
+struct da9062_thermal {
+ struct da9062 *hw;
+ struct delayed_work work;
+ struct thermal_zone_device *zone;
+ enum thermal_device_mode mode;
+ struct mutex lock; /* protection for da9062_thermal temperature */
+ int temperature;
+ int irq;
+ const struct da9062_thermal_config *config;
+ struct device *dev;
+};
+
+static void da9062_thermal_poll_on(struct work_struct *work)
+{
+ struct da9062_thermal *thermal = container_of(work,
+ struct da9062_thermal,
+ work.work);
+ unsigned long delay;
+ unsigned int val;
+ int ret;
+
+ /* clear E_TEMP */
+ ret = regmap_write(thermal->hw->regmap,
+ DA9062AA_EVENT_B,
+ DA9062AA_E_TEMP_MASK);
+ if (ret < 0) {
+ dev_err(thermal->dev,
+ "Cannot clear the TJUNC temperature status\n");
+ goto err_enable_irq;
+ }
+
+ /* Now read E_TEMP again: it is acting like a status bit.
+ * If over-temperature, then this status will be true.
+ * If not over-temperature, this status will be false.
+ */
+ ret = regmap_read(thermal->hw->regmap,
+ DA9062AA_EVENT_B,
+ &val);
+ if (ret < 0) {
+ dev_err(thermal->dev,
+ "Cannot check the TJUNC temperature status\n");
+ goto err_enable_irq;
+ }
+
+ if (val & DA9062AA_E_TEMP_MASK) {
+ mutex_lock(&thermal->lock);
+ thermal->temperature = DA9062_MILLI_CELSIUS(125);
+ mutex_unlock(&thermal->lock);
+ thermal_zone_device_update(thermal->zone,
+ THERMAL_EVENT_UNSPECIFIED);
+
+ delay = msecs_to_jiffies(thermal->zone->passive_delay);
+ schedule_delayed_work(&thermal->work, delay);
+ return;
+ }
+
+ mutex_lock(&thermal->lock);
+ thermal->temperature = DA9062_MILLI_CELSIUS(0);
+ mutex_unlock(&thermal->lock);
+ thermal_zone_device_update(thermal->zone,
+ THERMAL_EVENT_UNSPECIFIED);
+
+err_enable_irq:
+ enable_irq(thermal->irq);
+}
+
+static irqreturn_t da9062_thermal_irq_handler(int irq, void *data)
+{
+ struct da9062_thermal *thermal = data;
+
+ disable_irq_nosync(thermal->irq);
+ schedule_delayed_work(&thermal->work, 0);
+
+ return IRQ_HANDLED;
+}
+
+static int da9062_thermal_get_mode(struct thermal_zone_device *z,
+ enum thermal_device_mode *mode)
+{
+ struct da9062_thermal *thermal = z->devdata;
+ *mode = thermal->mode;
+ return 0;
+}
+
+static int da9062_thermal_get_trip_type(struct thermal_zone_device *z,
+ int trip,
+ enum thermal_trip_type *type)
+{
+ struct da9062_thermal *thermal = z->devdata;
+
+ switch (trip) {
+ case 0:
+ *type = THERMAL_TRIP_HOT;
+ break;
+ default:
+ dev_err(thermal->dev,
+ "Driver does not support more than 1 trip-wire\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int da9062_thermal_get_trip_temp(struct thermal_zone_device *z,
+ int trip,
+ int *temp)
+{
+ struct da9062_thermal *thermal = z->devdata;
+
+ switch (trip) {
+ case 0:
+ *temp = DA9062_MILLI_CELSIUS(125);
+ break;
+ default:
+ dev_err(thermal->dev,
+ "Driver does not support more than 1 trip-wire\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int da9062_thermal_get_temp(struct thermal_zone_device *z,
+ int *temp)
+{
+ struct da9062_thermal *thermal = z->devdata;
+
+ mutex_lock(&thermal->lock);
+ *temp = thermal->temperature;
+ mutex_unlock(&thermal->lock);
+
+ return 0;
+}
+
+static struct thermal_zone_device_ops da9062_thermal_ops = {
+ .get_temp = da9062_thermal_get_temp,
+ .get_mode = da9062_thermal_get_mode,
+ .get_trip_type = da9062_thermal_get_trip_type,
+ .get_trip_temp = da9062_thermal_get_trip_temp,
+};
+
+static const struct da9062_thermal_config da9062_config = {
+ .name = "da9062-thermal",
+};
+
+static const struct of_device_id da9062_compatible_reg_id_table[] = {
+ { .compatible = "dlg,da9062-thermal", .data = &da9062_config },
+ { },
+};
+
+MODULE_DEVICE_TABLE(of, da9062_compatible_reg_id_table);
+
+static int da9062_thermal_probe(struct platform_device *pdev)
+{
+ struct da9062 *chip = dev_get_drvdata(pdev->dev.parent);
+ struct da9062_thermal *thermal;
+ unsigned int pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
+ const struct of_device_id *match;
+ int ret = 0;
+
+ match = of_match_node(da9062_compatible_reg_id_table,
+ pdev->dev.of_node);
+ if (!match)
+ return -ENXIO;
+
+ if (pdev->dev.of_node) {
+ if (!of_property_read_u32(pdev->dev.of_node,
+ "polling-delay-passive",
+ &pp_tmp)) {
+ if (pp_tmp < DA9062_MIN_POLLING_MS_PERIOD ||
+ pp_tmp > DA9062_MAX_POLLING_MS_PERIOD) {
+ dev_warn(&pdev->dev,
+ "Out-of-range polling period %d ms\n",
+ pp_tmp);
+ pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
+ }
+ }
+ }
+
+ thermal = devm_kzalloc(&pdev->dev, sizeof(struct da9062_thermal),
+ GFP_KERNEL);
+ if (!thermal) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ thermal->config = match->data;
+ thermal->hw = chip;
+ thermal->mode = THERMAL_DEVICE_ENABLED;
+ thermal->dev = &pdev->dev;
+
+ INIT_DELAYED_WORK(&thermal->work, da9062_thermal_poll_on);
+ mutex_init(&thermal->lock);
+
+ thermal->zone = thermal_zone_device_register(thermal->config->name,
+ 1, 0, thermal,
+ &da9062_thermal_ops, NULL, pp_tmp,
+ 0);
+ if (IS_ERR(thermal->zone)) {
+ dev_err(&pdev->dev, "Cannot register thermal zone device\n");
+ ret = PTR_ERR(thermal->zone);
+ goto err;
+ }
+
+ dev_dbg(&pdev->dev,
+ "TJUNC temperature polling period set at %d ms\n",
+ thermal->zone->passive_delay);
+
+ ret = platform_get_irq_byname(pdev, "THERMAL");
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Failed to get platform IRQ.\n");
+ goto err_zone;
+ }
+ thermal->irq = ret;
+
+ ret = request_threaded_irq(thermal->irq, NULL,
+ da9062_thermal_irq_handler,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ "THERMAL", thermal);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Failed to request thermal device IRQ.\n");
+ goto err_zone;
+ }
+
+ platform_set_drvdata(pdev, thermal);
+ return 0;
+
+err_zone:
+ thermal_zone_device_unregister(thermal->zone);
+err:
+ return ret;
+}
+
+static int da9062_thermal_remove(struct platform_device *pdev)
+{
+ struct da9062_thermal *thermal = platform_get_drvdata(pdev);
+
+ free_irq(thermal->irq, thermal);
+ cancel_delayed_work_sync(&thermal->work);
+ thermal_zone_device_unregister(thermal->zone);
+ return 0;
+}
+
+static struct platform_driver da9062_thermal_driver = {
+ .probe = da9062_thermal_probe,
+ .remove = da9062_thermal_remove,
+ .driver = {
+ .name = "da9062-thermal",
+ .of_match_table = da9062_compatible_reg_id_table,
+ },
+};
+
+module_platform_driver(da9062_thermal_driver);
+
+MODULE_AUTHOR("Steve Twiss");
+MODULE_DESCRIPTION("Thermal TJUNC device driver for Dialog DA9062 and DA9061");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:da9062-thermal");
--
end-of-patch for PATCH V6
^ permalink raw reply related
* [PATCH V6 0/7] da9061: DA9061 driver submission
From: Steve Twiss @ 2017-03-27 9:51 UTC (permalink / raw)
To: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, Guenter Roeck,
LINUX-INPUT, LINUX-KERNEL, LINUX-PM, LINUX-WATCHDOG, Lee Jones,
Liam Girdwood, Lukasz Luba, Mark Brown, Mark Rutland, Rob Herring,
Steve Twiss, Wim Van Sebroeck, Zhang Rui
Cc: Support Opensource
From: Steve Twiss <stwiss.opensource@diasemi.com>
This patch set adds support for the Dialog DA9061 Power Management IC.
Support is made by altering the existing DA9062 device driver, where
appropriate.
In this patch set the following is provided:
[PATCH V5 1/8] Binding for watchdog
[PATCH V5 2/8] Binding for thermal supervisor
[PATCH V5 3/8] Binding for MFD and regulators
[PATCH V5 4/8] MFD core support
[PATCH V5 5/8] BUCKs and LDOs
[PATCH V5 6/8] Watchdog
[PATCH V5 7/8] PMIC temperature monitoring
[PATCH V5 8/8] MAINTAINERS update
Hello,
The only minor changes this time.
- minor comments to the thermal driver
- rebase from v4.9 to v4.11-rc3
- update the copyright header for the Dialog Legal dept
- fix checkpatch warnings
- add Acked-by
Some previous patches from this set have been applied already:
- Onkey binding
- Onkey driver
- Watchdog driver
This patch applies against linux-next and v4.11-rc3
Thank you,
Steve Twiss, Dialog Semiconductor
Steve Twiss (7):
Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
Documentation: devicetree: thermal: da9062/61 TJUNC temperature
binding
Documentation: devicetree: mfd: da9062/61 MFD binding
mfd: da9061: MFD core support
regulator: da9061: BUCK and LDO regulator driver
thermal: da9062/61: Thermal junction temperature monitoring driver
MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search
terms
Documentation/devicetree/bindings/mfd/da9062.txt | 49 ++-
.../devicetree/bindings/thermal/da9062-thermal.txt | 37 ++
.../devicetree/bindings/watchdog/da9062-wdt.txt | 23 ++
MAINTAINERS | 4 +
drivers/mfd/Kconfig | 5 +-
drivers/mfd/da9062-core.c | 427 ++++++++++++++++++++-
drivers/regulator/Kconfig | 4 +-
drivers/regulator/da9062-regulator.c | 303 ++++++++++++++-
drivers/thermal/Kconfig | 10 +
drivers/thermal/Makefile | 1 +
drivers/thermal/da9062-thermal.c | 315 +++++++++++++++
include/linux/mfd/da9062/core.h | 29 +-
include/linux/mfd/da9062/registers.h | 5 +-
13 files changed, 1162 insertions(+), 50 deletions(-)
create mode 100644 Documentation/devicetree/bindings/thermal/da9062-thermal.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
create mode 100644 drivers/thermal/da9062-thermal.c
--
end-of-patch for PATCH V6
^ permalink raw reply
* [PATCH V6 5/7] regulator: da9061: BUCK and LDO regulator driver
From: Steve Twiss @ 2017-03-27 9:51 UTC (permalink / raw)
To: LINUX-KERNEL, Liam Girdwood, Mark Brown
Cc: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, Guenter Roeck,
LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG, Lee Jones, Mark Rutland,
Rob Herring, Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <cover.1490608293.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Regulator support for the DA9061 is added into the DA9062 regulator driver.
The regulators for DA9061 differ from those of DA9062.
A new DA9061 enumeration list for the LDOs and Bucks supported by this
device is added. Regulator information added: the old regulator
information for DA9062 is renamed from local_regulator_info[] to
local_da9062_regulator_info[] and a new array is added to support
local_da9061_regulator_info[].
The probe() function switches on the da9062_compatible_types enumeration
and configures the correct da9062_regulator_info array and number of
regulator entries.
Kconfig is updated to reflect support for DA9061 and DA9062 regulators.
Acked-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
---
This patch applies against linux-next and v4.11-rc3
v5 -> v6
- Rebased from v4.9 to v4.11-rc3
- Modify Copyright to match Dialog latest legal statement
v4 -> v5
- Rebased from v4.8 to v4.9
- NO CODE CHANGE
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 6/9] to [PATCH V4 5/8]
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 06/10] to [PATCH V3 6/9]
- Added Ack from Mark Brown
v1 -> v2
- Patch renamed from [PATCH V1 02/10] to [PATCH V2 06/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Updated header to use DA9061 and DA9062
Hi,
Updated copyright header slightly to match Dialog's legal expectation.
No code changes for this version PATCH V5.
As previously:
These changes depend on a header file provided as part of an earlier
patch [PATCH V5 4/8] from this set. The regulator probe() switches on
the chip_type which uses enum da9062_compatible_types in core.h from this
patch.
Regards,
Steve Twiss, Dialog Semiconductor
drivers/regulator/Kconfig | 4 +-
drivers/regulator/da9062-regulator.c | 303 +++++++++++++++++++++++++++++++++--
2 files changed, 293 insertions(+), 14 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index be06eb2..c2e67f12 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -195,11 +195,11 @@ config REGULATOR_DA9055
will be called da9055-regulator.
config REGULATOR_DA9062
- tristate "Dialog Semiconductor DA9062 regulators"
+ tristate "Dialog Semiconductor DA9061/62 regulators"
depends on MFD_DA9062
help
Say y here to support the BUCKs and LDOs regulators found on
- DA9062 PMICs.
+ DA9061 and DA9062 PMICs.
This driver can also be built as a module. If so, the module
will be called da9062-regulator.
diff --git a/drivers/regulator/da9062-regulator.c b/drivers/regulator/da9062-regulator.c
index 0638c8b..34a70d9 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -1,6 +1,6 @@
/*
- * da9062-regulator.c - REGULATOR device driver for DA9062
- * Copyright (C) 2015 Dialog Semiconductor Ltd.
+ * Regulator device driver for DA9061 and DA9062.
+ * Copyright (C) 2015-2017 Dialog Semiconductor
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -28,6 +28,17 @@
/* Regulator IDs */
enum {
+ DA9061_ID_BUCK1,
+ DA9061_ID_BUCK2,
+ DA9061_ID_BUCK3,
+ DA9061_ID_LDO1,
+ DA9061_ID_LDO2,
+ DA9061_ID_LDO3,
+ DA9061_ID_LDO4,
+ DA9061_MAX_REGULATORS,
+};
+
+enum {
DA9062_ID_BUCK1,
DA9062_ID_BUCK2,
DA9062_ID_BUCK3,
@@ -88,15 +99,21 @@ enum {
/* Regulator operations */
-/* Current limits array (in uA) BUCK1 and BUCK3.
- Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_[BUCK1|BUCK3]
+ * - DA9062_ID_[BUCK1|BUCK2|BUCK4]
+ * Entry indexes corresponds to register values.
+ */
static const int da9062_buck_a_limits[] = {
500000, 600000, 700000, 800000, 900000, 1000000, 1100000, 1200000,
1300000, 1400000, 1500000, 1600000, 1700000, 1800000, 1900000, 2000000
};
-/* Current limits array (in uA) for BUCK2.
- Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_BUCK2
+ * - DA9062_ID_BUCK3
+ * Entry indexes corresponds to register values.
+ */
static const int da9062_buck_b_limits[] = {
1500000, 1600000, 1700000, 1800000, 1900000, 2000000, 2100000, 2200000,
2300000, 2400000, 2500000, 2600000, 2700000, 2800000, 2900000, 3000000
@@ -405,8 +422,254 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev,
.set_suspend_mode = da9062_ldo_set_suspend_mode,
};
-/* Regulator information */
-static const struct da9062_regulator_info local_regulator_info[] = {
+/* DA9061 Regulator information */
+static const struct da9062_regulator_info local_da9061_regulator_info[] = {
+ {
+ .desc.id = DA9061_ID_BUCK1,
+ .desc.name = "DA9061 BUCK1",
+ .desc.of_match = of_match_ptr("buck1"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_buck_ops,
+ .desc.min_uV = (300) * 1000,
+ .desc.uV_step = (10) * 1000,
+ .desc.n_voltages = ((1570) - (300))/(10) + 1,
+ .current_limits = da9062_buck_a_limits,
+ .n_current_limits = ARRAY_SIZE(da9062_buck_a_limits),
+ .desc.enable_reg = DA9062AA_BUCK1_CONT,
+ .desc.enable_mask = DA9062AA_BUCK1_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VBUCK1_A,
+ .desc.vsel_mask = DA9062AA_VBUCK1_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VBUCK1_A,
+ __builtin_ffs((int)DA9062AA_BUCK1_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VBUCK1_B,
+ __builtin_ffs((int)DA9062AA_BUCK1_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VBUCK1_B,
+ .mode = REG_FIELD(DA9062AA_BUCK1_CFG,
+ __builtin_ffs((int)DA9062AA_BUCK1_MODE_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_MODE_MASK)) - 1),
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VBUCK1_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VBUCK1_SEL_MASK)) - 1),
+ .ilimit = REG_FIELD(DA9062AA_BUCK_ILIM_C,
+ __builtin_ffs((int)DA9062AA_BUCK1_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_BUCK2,
+ .desc.name = "DA9061 BUCK2",
+ .desc.of_match = of_match_ptr("buck2"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_buck_ops,
+ .desc.min_uV = (800) * 1000,
+ .desc.uV_step = (20) * 1000,
+ .desc.n_voltages = ((3340) - (800))/(20) + 1,
+ .current_limits = da9062_buck_b_limits,
+ .n_current_limits = ARRAY_SIZE(da9062_buck_b_limits),
+ .desc.enable_reg = DA9062AA_BUCK3_CONT,
+ .desc.enable_mask = DA9062AA_BUCK3_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VBUCK3_A,
+ .desc.vsel_mask = DA9062AA_VBUCK3_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VBUCK3_A,
+ __builtin_ffs((int)DA9062AA_BUCK3_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VBUCK3_B,
+ __builtin_ffs((int)DA9062AA_BUCK3_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VBUCK3_B,
+ .mode = REG_FIELD(DA9062AA_BUCK3_CFG,
+ __builtin_ffs((int)DA9062AA_BUCK3_MODE_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_MODE_MASK)) - 1),
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VBUCK3_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VBUCK3_SEL_MASK)) - 1),
+ .ilimit = REG_FIELD(DA9062AA_BUCK_ILIM_A,
+ __builtin_ffs((int)DA9062AA_BUCK3_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_BUCK3,
+ .desc.name = "DA9061 BUCK3",
+ .desc.of_match = of_match_ptr("buck3"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_buck_ops,
+ .desc.min_uV = (530) * 1000,
+ .desc.uV_step = (10) * 1000,
+ .desc.n_voltages = ((1800) - (530))/(10) + 1,
+ .current_limits = da9062_buck_a_limits,
+ .n_current_limits = ARRAY_SIZE(da9062_buck_a_limits),
+ .desc.enable_reg = DA9062AA_BUCK4_CONT,
+ .desc.enable_mask = DA9062AA_BUCK4_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VBUCK4_A,
+ .desc.vsel_mask = DA9062AA_VBUCK4_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VBUCK4_A,
+ __builtin_ffs((int)DA9062AA_BUCK4_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VBUCK4_B,
+ __builtin_ffs((int)DA9062AA_BUCK4_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VBUCK4_B,
+ .mode = REG_FIELD(DA9062AA_BUCK4_CFG,
+ __builtin_ffs((int)DA9062AA_BUCK4_MODE_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_MODE_MASK)) - 1),
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VBUCK4_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VBUCK4_SEL_MASK)) - 1),
+ .ilimit = REG_FIELD(DA9062AA_BUCK_ILIM_B,
+ __builtin_ffs((int)DA9062AA_BUCK4_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO1,
+ .desc.name = "DA9061 LDO1",
+ .desc.of_match = of_match_ptr("ldo1"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (900))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO1_CONT,
+ .desc.enable_mask = DA9062AA_LDO1_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO1_A,
+ .desc.vsel_mask = DA9062AA_VLDO1_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO1_A,
+ __builtin_ffs((int)DA9062AA_LDO1_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO1_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO1_B,
+ __builtin_ffs((int)DA9062AA_LDO1_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO1_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO1_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO1_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO1_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO1_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO1_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO2,
+ .desc.name = "DA9061 LDO2",
+ .desc.of_match = of_match_ptr("ldo2"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (600))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO2_CONT,
+ .desc.enable_mask = DA9062AA_LDO2_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO2_A,
+ .desc.vsel_mask = DA9062AA_VLDO2_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO2_A,
+ __builtin_ffs((int)DA9062AA_LDO2_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO2_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO2_B,
+ __builtin_ffs((int)DA9062AA_LDO2_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO2_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO2_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO2_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO2_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO2_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO2_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO3,
+ .desc.name = "DA9061 LDO3",
+ .desc.of_match = of_match_ptr("ldo3"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (900))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO3_CONT,
+ .desc.enable_mask = DA9062AA_LDO3_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO3_A,
+ .desc.vsel_mask = DA9062AA_VLDO3_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO3_A,
+ __builtin_ffs((int)DA9062AA_LDO3_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO3_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO3_B,
+ __builtin_ffs((int)DA9062AA_LDO3_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO3_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO3_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO3_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO3_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO3_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO3_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO4,
+ .desc.name = "DA9061 LDO4",
+ .desc.of_match = of_match_ptr("ldo4"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (900))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO4_CONT,
+ .desc.enable_mask = DA9062AA_LDO4_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO4_A,
+ .desc.vsel_mask = DA9062AA_VLDO4_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO4_A,
+ __builtin_ffs((int)DA9062AA_LDO4_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO4_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO4_B,
+ __builtin_ffs((int)DA9062AA_LDO4_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO4_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO4_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO4_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO4_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO4_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO4_ILIM_MASK)) - 1),
+ },
+};
+
+/* DA9062 Regulator information */
+static const struct da9062_regulator_info local_da9062_regulator_info[] = {
{
.desc.id = DA9062_ID_BUCK1,
.desc.name = "DA9062 BUCK1",
@@ -727,17 +990,33 @@ static int da9062_regulator_probe(struct platform_device *pdev)
struct da9062_regulators *regulators;
struct da9062_regulator *regl;
struct regulator_config config = { };
+ const struct da9062_regulator_info *rinfo;
int irq, n, ret;
size_t size;
+ int max_regulators;
+
+ switch (chip->chip_type) {
+ case COMPAT_TYPE_DA9061:
+ max_regulators = DA9061_MAX_REGULATORS;
+ rinfo = local_da9061_regulator_info;
+ break;
+ case COMPAT_TYPE_DA9062:
+ max_regulators = DA9062_MAX_REGULATORS;
+ rinfo = local_da9062_regulator_info;
+ break;
+ default:
+ dev_err(chip->dev, "Unrecognised chip type\n");
+ return -ENODEV;
+ }
/* Allocate memory required by usable regulators */
size = sizeof(struct da9062_regulators) +
- DA9062_MAX_REGULATORS * sizeof(struct da9062_regulator);
+ max_regulators * sizeof(struct da9062_regulator);
regulators = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
if (!regulators)
return -ENOMEM;
- regulators->n_regulators = DA9062_MAX_REGULATORS;
+ regulators->n_regulators = max_regulators;
platform_set_drvdata(pdev, regulators);
n = 0;
@@ -745,7 +1024,7 @@ static int da9062_regulator_probe(struct platform_device *pdev)
/* Initialise regulator structure */
regl = ®ulators->regulator[n];
regl->hw = chip;
- regl->info = &local_regulator_info[n];
+ regl->info = &rinfo[n];
regl->desc = regl->info->desc;
regl->desc.type = REGULATOR_VOLTAGE;
regl->desc.owner = THIS_MODULE;
@@ -836,6 +1115,6 @@ static void __exit da9062_regulator_cleanup(void)
/* Module information */
MODULE_AUTHOR("S Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>");
-MODULE_DESCRIPTION("REGULATOR device driver for Dialog DA9062");
+MODULE_DESCRIPTION("REGULATOR device driver for Dialog DA9062 and DA9061");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:da9062-regulators");
--
end-of-patch for PATCH V6
--
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 V6 4/7] mfd: da9061: MFD core support
From: Steve Twiss @ 2017-03-27 9:51 UTC (permalink / raw)
To: LINUX-KERNEL, Lee Jones
Cc: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, Guenter Roeck,
LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG, Liam Girdwood, Mark Brown,
Mark Rutland, Rob Herring, Support Opensource, Wim Van Sebroeck,
Zhang Rui
In-Reply-To: <cover.1490608293.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
MFD support for DA9061 is provided as part of the DA9062 device driver.
The registers header file adds two new chip variant IDs defined in DA9061
and DA9062 hardware. The core header file adds new software enumerations
for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
for distinguishing between DA9061/62 devices in software.
The core source code adds a new .compatible of_device_id entry. This is
extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
.data entry now holds a reference to the enumerated device type.
A new regmap_irq_chip model is added for DA9061 and this supports the new
list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
new sub system components for DA9061. Support is added for a new DA9061
regmap_config which lists the correct readable, writable and volatile
ranges for this chip.
The probe function uses the device tree compatible string to switch on the
da9062_compatible_types and configure the correct mfd cells, irq chip and
regmap config.
Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
Acked-for-mfd-by: Lee Jones <lee.jones@linaro.org>
Hi Lee, that Ack was from your earlier posting:
https://lkml.org/lkml/2017/1/4/328 this was
Regards, Steve.
This patch applies against linux-next and v4.11-rc3
v5 -> v6
- Rebased from v4.9 to v4.11-rc3
- Modify Copyright to match Dialog latest legal statement
- Fixed "braces {} should be used on all arms" checkpatch warning
v4 -> v5
- NO CODE CHANGE
- Rebased from v4.8 to v4.9
v3 -> v4
- Patch renamed from [PATCH V3 5/9] to [PATCH V4 4/8]
- Removed DEFINE_RES_NAMED() macros for DA9061 resources and replaced
them with DEFINE_RES_IRQ_NAMED().
- Removed whitespace
- Reverted change for badly defined mfd_cell da9062_devs of_compatible
string from "dlg,da9062-watchdog" back to "dlg,da9062-wdt"
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 05/10] to [PATCH V3 5/9]
v1 -> v2
- Patch renamed from [PATCH V1 01/10] to [PATCH V2 05/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Fixed typo in the commit message "readble" to "readable"
- Removed the explicit cross-check to decide if there is a conflict
between the device tree compatible string and the hardware definition.
This patch assumes the device tree is correctly written and therefore
removes the need for a hardware/DT sanity check.
- Removed extra semicolon in drivers/mfd/da9062-core.c:877
- Re-write compatible entries into numerical order
Lee,
Changes as described in the version history above.
As previously:
This patch adds support for the DA9061 PMIC. This is done as part of the
existing DA9062 device driver by extending the of_device_id match table.
This in turn allows new MFD cells, irq chip and regmap definitions to
support DA9061.
Regards,
Steve Twiss, Dialog Semiconductor
drivers/mfd/Kconfig | 5 +-
drivers/mfd/da9062-core.c | 427 +++++++++++++++++++++++++++++++++--
include/linux/mfd/da9062/core.h | 29 ++-
include/linux/mfd/da9062/registers.h | 5 +-
4 files changed, 443 insertions(+), 23 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 55ecdfb..29cc11a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -263,13 +263,14 @@ config MFD_DA9055
called "da9055"
config MFD_DA9062
- tristate "Dialog Semiconductor DA9062 PMIC Support"
+ tristate "Dialog Semiconductor DA9062/61 PMIC Support"
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
depends on I2C
help
- Say yes here for support for the Dialog Semiconductor DA9062 PMIC.
+ Say yes here for support for the Dialog Semiconductor DA9061 and
+ DA9062 PMICs.
This includes the I2C driver and core APIs.
Additional drivers must be enabled in order to use the functionality
of the device.
diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
index 8f873866..9310eaf 100644
--- a/drivers/mfd/da9062-core.c
+++ b/drivers/mfd/da9062-core.c
@@ -1,6 +1,6 @@
/*
- * Core, IRQ and I2C device driver for DA9062 PMIC
- * Copyright (C) 2015 Dialog Semiconductor Ltd.
+ * Core, IRQ and I2C device driver for DA9061 and DA9062 PMICs
+ * Copyright (C) 2015-2017 Dialog Semiconductor
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -30,6 +30,70 @@
#define DA9062_REG_EVENT_B_OFFSET 1
#define DA9062_REG_EVENT_C_OFFSET 2
+static struct regmap_irq da9061_irqs[] = {
+ /* EVENT A */
+ [DA9061_IRQ_ONKEY] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_NONKEY_MASK,
+ },
+ [DA9061_IRQ_WDG_WARN] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_WDG_WARN_MASK,
+ },
+ [DA9061_IRQ_SEQ_RDY] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_SEQ_RDY_MASK,
+ },
+ /* EVENT B */
+ [DA9061_IRQ_TEMP] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_TEMP_MASK,
+ },
+ [DA9061_IRQ_LDO_LIM] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_LDO_LIM_MASK,
+ },
+ [DA9061_IRQ_DVC_RDY] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_DVC_RDY_MASK,
+ },
+ [DA9061_IRQ_VDD_WARN] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_VDD_WARN_MASK,
+ },
+ /* EVENT C */
+ [DA9061_IRQ_GPI0] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI0_MASK,
+ },
+ [DA9061_IRQ_GPI1] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI1_MASK,
+ },
+ [DA9061_IRQ_GPI2] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI2_MASK,
+ },
+ [DA9061_IRQ_GPI3] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI3_MASK,
+ },
+ [DA9061_IRQ_GPI4] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI4_MASK,
+ },
+};
+
+static struct regmap_irq_chip da9061_irq_chip = {
+ .name = "da9061-irq",
+ .irqs = da9061_irqs,
+ .num_irqs = DA9061_NUM_IRQ,
+ .num_regs = 3,
+ .status_base = DA9062AA_EVENT_A,
+ .mask_base = DA9062AA_IRQ_MASK_A,
+ .ack_base = DA9062AA_EVENT_A,
+};
+
static struct regmap_irq da9062_irqs[] = {
/* EVENT A */
[DA9062_IRQ_ONKEY] = {
@@ -102,6 +166,57 @@
.ack_base = DA9062AA_EVENT_A,
};
+static struct resource da9061_core_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_VDD_WARN, "VDD_WARN"),
+};
+
+static struct resource da9061_regulators_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_LDO_LIM, "LDO_LIM"),
+};
+
+static struct resource da9061_thermal_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_TEMP, "THERMAL"),
+};
+
+static struct resource da9061_wdt_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_WDG_WARN, "WD_WARN"),
+};
+
+static struct resource da9061_onkey_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_ONKEY, "ONKEY"),
+};
+
+static const struct mfd_cell da9061_devs[] = {
+ {
+ .name = "da9061-core",
+ .num_resources = ARRAY_SIZE(da9061_core_resources),
+ .resources = da9061_core_resources,
+ },
+ {
+ .name = "da9062-regulators",
+ .num_resources = ARRAY_SIZE(da9061_regulators_resources),
+ .resources = da9061_regulators_resources,
+ },
+ {
+ .name = "da9061-watchdog",
+ .num_resources = ARRAY_SIZE(da9061_wdt_resources),
+ .resources = da9061_wdt_resources,
+ .of_compatible = "dlg,da9061-watchdog",
+ },
+ {
+ .name = "da9061-thermal",
+ .num_resources = ARRAY_SIZE(da9061_thermal_resources),
+ .resources = da9061_thermal_resources,
+ .of_compatible = "dlg,da9061-thermal",
+ },
+ {
+ .name = "da9061-onkey",
+ .num_resources = ARRAY_SIZE(da9061_onkey_resources),
+ .resources = da9061_onkey_resources,
+ .of_compatible = "dlg,da9061-onkey",
+ },
+};
+
static struct resource da9062_core_resources[] = {
DEFINE_RES_NAMED(DA9062_IRQ_VDD_WARN, 1, "VDD_WARN", IORESOURCE_IRQ),
};
@@ -200,7 +315,8 @@ static int da9062_clear_fault_log(struct da9062 *chip)
static int da9062_get_device_type(struct da9062 *chip)
{
- int device_id, variant_id, variant_mrc;
+ int device_id, variant_id, variant_mrc, variant_vrc;
+ char *type;
int ret;
ret = regmap_read(chip->regmap, DA9062AA_DEVICE_ID, &device_id);
@@ -219,9 +335,23 @@ static int da9062_get_device_type(struct da9062 *chip)
return -EIO;
}
+ variant_vrc = (variant_id & DA9062AA_VRC_MASK) >> DA9062AA_VRC_SHIFT;
+
+ switch (variant_vrc) {
+ case DA9062_PMIC_VARIANT_VRC_DA9061:
+ type = "DA9061";
+ break;
+ case DA9062_PMIC_VARIANT_VRC_DA9062:
+ type = "DA9062";
+ break;
+ default:
+ type = "Unknown";
+ break;
+ }
+
dev_info(chip->dev,
- "Device detected (device-ID: 0x%02X, var-ID: 0x%02X)\n",
- device_id, variant_id);
+ "Device detected (device-ID: 0x%02X, var-ID: 0x%02X, %s)\n",
+ device_id, variant_id, type);
variant_mrc = (variant_id & DA9062AA_MRC_MASK) >> DA9062AA_MRC_SHIFT;
@@ -234,6 +364,234 @@ static int da9062_get_device_type(struct da9062 *chip)
return ret;
}
+static const struct regmap_range da9061_aa_readable_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_STATUS_B,
+ }, {
+ .range_min = DA9062AA_STATUS_D,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_IRQ_MASK_A,
+ .range_max = DA9062AA_IRQ_MASK_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_GPIO_4,
+ }, {
+ .range_min = DA9062AA_GPIO_WKUP_MODE,
+ .range_max = DA9062AA_GPIO_OUT3_4,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_ID_4_3,
+ }, {
+ .range_min = DA9062AA_ID_12_11,
+ .range_max = DA9062AA_ID_16_15,
+ }, {
+ .range_min = DA9062AA_ID_22_21,
+ .range_max = DA9062AA_ID_32_31,
+ }, {
+ .range_min = DA9062AA_SEQ_A,
+ .range_max = DA9062AA_WAIT,
+ }, {
+ .range_min = DA9062AA_RESET,
+ .range_max = DA9062AA_BUCK_ILIM_C,
+ }, {
+ .range_min = DA9062AA_BUCK1_CFG,
+ .range_max = DA9062AA_BUCK3_CFG,
+ }, {
+ .range_min = DA9062AA_VBUCK1_A,
+ .range_max = DA9062AA_VBUCK4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK3_A,
+ .range_max = DA9062AA_VBUCK3_A,
+ }, {
+ .range_min = DA9062AA_VLDO1_A,
+ .range_max = DA9062AA_VLDO4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK1_B,
+ .range_max = DA9062AA_VBUCK4_B,
+ }, {
+ .range_min = DA9062AA_VBUCK3_B,
+ .range_max = DA9062AA_VBUCK3_B,
+ }, {
+ .range_min = DA9062AA_VLDO1_B,
+ .range_max = DA9062AA_VLDO4_B,
+ }, {
+ .range_min = DA9062AA_BBAT_CONT,
+ .range_max = DA9062AA_BBAT_CONT,
+ }, {
+ .range_min = DA9062AA_INTERFACE,
+ .range_max = DA9062AA_CONFIG_E,
+ }, {
+ .range_min = DA9062AA_CONFIG_G,
+ .range_max = DA9062AA_CONFIG_K,
+ }, {
+ .range_min = DA9062AA_CONFIG_M,
+ .range_max = DA9062AA_CONFIG_M,
+ }, {
+ .range_min = DA9062AA_GP_ID_0,
+ .range_max = DA9062AA_GP_ID_19,
+ }, {
+ .range_min = DA9062AA_DEVICE_ID,
+ .range_max = DA9062AA_CONFIG_ID,
+ },
+};
+
+static const struct regmap_range da9061_aa_writeable_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_PAGE_CON,
+ }, {
+ .range_min = DA9062AA_FAULT_LOG,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_IRQ_MASK_A,
+ .range_max = DA9062AA_IRQ_MASK_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_GPIO_4,
+ }, {
+ .range_min = DA9062AA_GPIO_WKUP_MODE,
+ .range_max = DA9062AA_GPIO_OUT3_4,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_ID_4_3,
+ }, {
+ .range_min = DA9062AA_ID_12_11,
+ .range_max = DA9062AA_ID_16_15,
+ }, {
+ .range_min = DA9062AA_ID_22_21,
+ .range_max = DA9062AA_ID_32_31,
+ }, {
+ .range_min = DA9062AA_SEQ_A,
+ .range_max = DA9062AA_WAIT,
+ }, {
+ .range_min = DA9062AA_RESET,
+ .range_max = DA9062AA_BUCK_ILIM_C,
+ }, {
+ .range_min = DA9062AA_BUCK1_CFG,
+ .range_max = DA9062AA_BUCK3_CFG,
+ }, {
+ .range_min = DA9062AA_VBUCK1_A,
+ .range_max = DA9062AA_VBUCK4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK3_A,
+ .range_max = DA9062AA_VBUCK3_A,
+ }, {
+ .range_min = DA9062AA_VLDO1_A,
+ .range_max = DA9062AA_VLDO4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK1_B,
+ .range_max = DA9062AA_VBUCK4_B,
+ }, {
+ .range_min = DA9062AA_VBUCK3_B,
+ .range_max = DA9062AA_VBUCK3_B,
+ }, {
+ .range_min = DA9062AA_VLDO1_B,
+ .range_max = DA9062AA_VLDO4_B,
+ }, {
+ .range_min = DA9062AA_BBAT_CONT,
+ .range_max = DA9062AA_BBAT_CONT,
+ }, {
+ .range_min = DA9062AA_GP_ID_0,
+ .range_max = DA9062AA_GP_ID_19,
+ },
+};
+
+static const struct regmap_range da9061_aa_volatile_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_STATUS_B,
+ }, {
+ .range_min = DA9062AA_STATUS_D,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_CONTROL_B,
+ }, {
+ .range_min = DA9062AA_CONTROL_E,
+ .range_max = DA9062AA_CONTROL_F,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_SEQ,
+ },
+};
+
+static const struct regmap_access_table da9061_aa_readable_table = {
+ .yes_ranges = da9061_aa_readable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_readable_ranges),
+};
+
+static const struct regmap_access_table da9061_aa_writeable_table = {
+ .yes_ranges = da9061_aa_writeable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_writeable_ranges),
+};
+
+static const struct regmap_access_table da9061_aa_volatile_table = {
+ .yes_ranges = da9061_aa_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_volatile_ranges),
+};
+
+static const struct regmap_range_cfg da9061_range_cfg[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_CONFIG_ID,
+ .selector_reg = DA9062AA_PAGE_CON,
+ .selector_mask = 1 << DA9062_I2C_PAGE_SEL_SHIFT,
+ .selector_shift = DA9062_I2C_PAGE_SEL_SHIFT,
+ .window_start = 0,
+ .window_len = 256,
+ }
+};
+
+static struct regmap_config da9061_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .ranges = da9061_range_cfg,
+ .num_ranges = ARRAY_SIZE(da9061_range_cfg),
+ .max_register = DA9062AA_CONFIG_ID,
+ .cache_type = REGCACHE_RBTREE,
+ .rd_table = &da9061_aa_readable_table,
+ .wr_table = &da9061_aa_writeable_table,
+ .volatile_table = &da9061_aa_volatile_table,
+};
+
static const struct regmap_range da9062_aa_readable_ranges[] = {
{
.range_min = DA9062AA_PAGE_CON,
@@ -456,17 +814,39 @@ static int da9062_get_device_type(struct da9062 *chip)
.volatile_table = &da9062_aa_volatile_table,
};
+static const struct of_device_id da9062_dt_ids[] = {
+ { .compatible = "dlg,da9061", .data = (void *)COMPAT_TYPE_DA9061, },
+ { .compatible = "dlg,da9062", .data = (void *)COMPAT_TYPE_DA9062, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, da9062_dt_ids);
+
static int da9062_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct da9062 *chip;
+ const struct of_device_id *match;
unsigned int irq_base;
+ const struct mfd_cell *cell;
+ const struct regmap_irq_chip *irq_chip;
+ const struct regmap_config *config;
+ int cell_num;
int ret;
chip = devm_kzalloc(&i2c->dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
return -ENOMEM;
+ if (i2c->dev.of_node) {
+ match = of_match_node(da9062_dt_ids, i2c->dev.of_node);
+ if (!match)
+ return -EINVAL;
+
+ chip->chip_type = (int)match->data;
+ } else {
+ chip->chip_type = id->driver_data;
+ }
+
i2c_set_clientdata(i2c, chip);
chip->dev = &i2c->dev;
@@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
return -EINVAL;
}
- chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
+ switch (chip->chip_type) {
+ case(COMPAT_TYPE_DA9061):
+ cell = da9061_devs;
+ cell_num = ARRAY_SIZE(da9061_devs);
+ irq_chip = &da9061_irq_chip;
+ config = &da9061_regmap_config;
+ break;
+ case(COMPAT_TYPE_DA9062):
+ cell = da9062_devs;
+ cell_num = ARRAY_SIZE(da9062_devs);
+ irq_chip = &da9062_irq_chip;
+ config = &da9062_regmap_config;
+ break;
+ default:
+ dev_err(chip->dev, "Unrecognised chip type\n");
+ return -ENODEV;
+ }
+
+ chip->regmap = devm_regmap_init_i2c(i2c, config);
if (IS_ERR(chip->regmap)) {
ret = PTR_ERR(chip->regmap);
dev_err(chip->dev, "Failed to allocate register map: %d\n",
@@ -493,7 +891,7 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
ret = regmap_add_irq_chip(chip->regmap, i2c->irq,
IRQF_TRIGGER_LOW | IRQF_ONESHOT | IRQF_SHARED,
- -1, &da9062_irq_chip,
+ -1, irq_chip,
&chip->regmap_irq);
if (ret) {
dev_err(chip->dev, "Failed to request IRQ %d: %d\n",
@@ -503,8 +901,8 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
irq_base = regmap_irq_chip_get_base(chip->regmap_irq);
- ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, da9062_devs,
- ARRAY_SIZE(da9062_devs), NULL, irq_base,
+ ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, cell,
+ cell_num, NULL, irq_base,
NULL);
if (ret) {
dev_err(chip->dev, "Cannot register child devices\n");
@@ -526,17 +924,12 @@ static int da9062_i2c_remove(struct i2c_client *i2c)
}
static const struct i2c_device_id da9062_i2c_id[] = {
- { "da9062", 0 },
+ { "da9061", COMPAT_TYPE_DA9061 },
+ { "da9062", COMPAT_TYPE_DA9062 },
{ },
};
MODULE_DEVICE_TABLE(i2c, da9062_i2c_id);
-static const struct of_device_id da9062_dt_ids[] = {
- { .compatible = "dlg,da9062", },
- { }
-};
-MODULE_DEVICE_TABLE(of, da9062_dt_ids);
-
static struct i2c_driver da9062_i2c_driver = {
.driver = {
.name = "da9062",
@@ -549,6 +942,6 @@ static int da9062_i2c_remove(struct i2c_client *i2c)
module_i2c_driver(da9062_i2c_driver);
-MODULE_DESCRIPTION("Core device driver for Dialog DA9062");
+MODULE_DESCRIPTION("Core device driver for Dialog DA9061 and DA9062");
MODULE_AUTHOR("Steve Twiss <stwiss.opensource@diasemi.com>");
MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/da9062/core.h b/include/linux/mfd/da9062/core.h
index 376ba84..74d33a0 100644
--- a/include/linux/mfd/da9062/core.h
+++ b/include/linux/mfd/da9062/core.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2015 Dialog Semiconductor Ltd.
+ * Copyright (C) 2015-2017 Dialog Semiconductor
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -18,7 +18,31 @@
#include <linux/interrupt.h>
#include <linux/mfd/da9062/registers.h>
-/* Interrupts */
+enum da9062_compatible_types {
+ COMPAT_TYPE_DA9061 = 1,
+ COMPAT_TYPE_DA9062,
+};
+
+enum da9061_irqs {
+ /* IRQ A */
+ DA9061_IRQ_ONKEY,
+ DA9061_IRQ_WDG_WARN,
+ DA9061_IRQ_SEQ_RDY,
+ /* IRQ B*/
+ DA9061_IRQ_TEMP,
+ DA9061_IRQ_LDO_LIM,
+ DA9061_IRQ_DVC_RDY,
+ DA9061_IRQ_VDD_WARN,
+ /* IRQ C */
+ DA9061_IRQ_GPI0,
+ DA9061_IRQ_GPI1,
+ DA9061_IRQ_GPI2,
+ DA9061_IRQ_GPI3,
+ DA9061_IRQ_GPI4,
+
+ DA9061_NUM_IRQ,
+};
+
enum da9062_irqs {
/* IRQ A */
DA9062_IRQ_ONKEY,
@@ -45,6 +69,7 @@ struct da9062 {
struct device *dev;
struct regmap *regmap;
struct regmap_irq_chip_data *regmap_irq;
+ enum da9062_compatible_types chip_type;
};
#endif /* __MFD_DA9062_CORE_H__ */
diff --git a/include/linux/mfd/da9062/registers.h b/include/linux/mfd/da9062/registers.h
index 97790d1..18d576a 100644
--- a/include/linux/mfd/da9062/registers.h
+++ b/include/linux/mfd/da9062/registers.h
@@ -1,6 +1,5 @@
/*
- * registers.h - REGISTERS H for DA9062
- * Copyright (C) 2015 Dialog Semiconductor Ltd.
+ * Copyright (C) 2015-2017 Dialog Semiconductor
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -18,6 +17,8 @@
#define DA9062_PMIC_DEVICE_ID 0x62
#define DA9062_PMIC_VARIANT_MRC_AA 0x01
+#define DA9062_PMIC_VARIANT_VRC_DA9061 0x01
+#define DA9062_PMIC_VARIANT_VRC_DA9062 0x02
#define DA9062_I2C_PAGE_SEL_SHIFT 1
--
end-of-patch for PATCH V6
^ permalink raw reply related
* [PATCH V6 2/7] Documentation: devicetree: thermal: da9062/61 TJUNC temperature binding
From: Steve Twiss @ 2017-03-27 9:51 UTC (permalink / raw)
To: DEVICETREE, Eduardo Valentin, LINUX-KERNEL, LINUX-PM,
Mark Rutland, Rob Herring, Zhang Rui
Cc: Dmitry Torokhov, Guenter Roeck, LINUX-INPUT, LINUX-WATCHDOG,
Lee Jones, Liam Girdwood, Lukasz Luba, Mark Brown,
Support Opensource, Wim Van Sebroeck
In-Reply-To: <cover.1490608293.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Device tree binding information for DA9062 and DA9061 thermal junction
temperature monitor.
Binding descriptions for the DA9061 and DA9062 thermal TJUNC supervisor
device driver, using a single THERMAL_TRIP_HOT trip-wire and allowing for
a configurable polling period for over-temperature polling.
This patch also adds two examples, one for DA9062 and one for DA9061. The
DA9061 example uses a fall-back compatible string for the DA9062.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
---
This patch applies against linux-next and v4.11-rc3
v5 -> v6
- NO CODE CHANGE
- Rebased from v4.9 to v4.11-rc3
- Added Acked-by Rob Herring
v4 -> v5
- Rebased from v4.8 to v4.9
- Updates from comments by Eduardo Valentin
- Replace vendor defined dlg,tjunc-temp-polling-period-ms with standard
thermal core polling-delay-passive as part of the device tree
initialisation
- Remove Acked-by Rob Herring
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 3/9] to [PATCH V4 2/8]
- Added Acked-by Rob Herring
v2 -> v3
- Patch renamed from [PATCH V2 03/10] to [PATCH V3 3/9]
- Changes suggested from other component reviews by Rob Herring:
- Each compatible line should be a valid combination of compatible
strings: alter DA9061 line to include the fall back compatible string
and update the commit message accordingly
- Add e-mail information about associated patches from this set without
describing them as being explicitly dependent on this binding
v1 -> v2
- Patch renamed from [PATCH V1 08/10] to [PATCH V2 03/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- A second example for DA9061 is provided to highlight the use of a
fall-back compatible option for the DA9062
Hi,
No code changes for this version PATCH V5.
As previously:
The device driver from this patch set (associated with this binding) is:
[PATCH V5 7/8] thermal: da9061: TJUNC temperature driver
Regards,
Steve Twiss, Dialog Semiconductor
.../devicetree/bindings/thermal/da9062-thermal.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/da9062-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/da9062-thermal.txt b/Documentation/devicetree/bindings/thermal/da9062-thermal.txt
new file mode 100644
index 0000000..08cc72e
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/da9062-thermal.txt
@@ -0,0 +1,37 @@
+* Dialog DA9062/61 TJUNC Thermal Module
+
+This module is part of the DA9061/DA9062. For more details about entire
+DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
+
+Junction temperature thermal module uses an interrupt signal to identify
+high THERMAL_TRIP_HOT temperatures for the PMIC device.
+
+Required properties:
+
+- compatible: should be one of the following valid compatible string lines:
+ "dlg,da9061-thermal", "dlg,da9062-thermal"
+ "dlg,da9062-thermal"
+
+Optional properties:
+
+- polling-delay-passive : Specify the polling period, measured in
+ milliseconds, between thermal zone device update checks.
+
+Example: DA9062
+
+ pmic0: da9062@58 {
+ thermal {
+ compatible = "dlg,da9062-thermal";
+ polling-delay-passive = <3000>;
+ };
+ };
+
+Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
+
+ pmic0: da9061@58 {
+ thermal {
+ compatible = "dlg,da9061-thermal", "dlg,da9062-thermal";
+ polling-delay-passive = <3000>;
+ };
+ };
+
--
end-of-patch for PATCH V6
--
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 V6 3/7] Documentation: devicetree: mfd: da9062/61 MFD binding
From: Steve Twiss @ 2017-03-27 9:51 UTC (permalink / raw)
To: DEVICETREE, LINUX-KERNEL, Mark Rutland, Rob Herring
Cc: Dmitry Torokhov, Eduardo Valentin, Guenter Roeck, LINUX-INPUT,
LINUX-PM, LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Mark Brown,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <cover.1490608293.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Extend existing DA9062 binding information to include the DA9061 PMIC for
MFD core and regulators.
Add a da9062-onkey link to the existing onkey binding file.
Add a da9062-thermal link to the new temperature monitoring binding file.
Delete the da9062-watchdog section and replace it with a link to the new
DA9061/62 binding information file.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
---
This patch applies against linux-next and v4.11-rc3
v5 -> v6
- NO CODE CHANGE
- Rebased from v4.9 to v4.11-rc3
v4 -> v5
- NO CODE CHANGE
- Rebased from v4.8 to v4.9
v3 -> v4
- Patch renamed from [PATCH V3 4/9] to [PATCH V4 3/8]
- Remove double newline spacing in text file
- Added Acked-by Rob Herring
v2 -> v3
- Patch renamed from [PATCH V2 04/10] to [PATCH V3 4/9]
- Ensure binding description concentrates on the device not the
device driver
- Separate the DA9061 and DA9062 sub-device tables to distinguish
the difference between the two devices
- Update the commit message to describe this change
- Add e-mail information about associated patches from this set
without describing them as being explicitly dependent on this
binding
v1 -> v2
- Patch renamed from [PATCH V1 09/10] to [PATCH V2 04/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
Hi,
Added an Ack from Rob Herring for the PATCH V3 version.
As previously:
Other information:
The device driver from this patch set (associated with this binding) is
- [PATCH V5 4/8] mfd: da9061: MFD core support
and also the following binding file changes:
- Binding for onkey (already applied by Dmitry Torokhov)
- [PATCH V5 1/8] Binding for watchdog
- [PATCH V5 2/8] Binding for thermal
Regards,
Steve Twiss, Dialog Semiconductor
Documentation/devicetree/bindings/mfd/da9062.txt | 49 +++++++++++++++++-------
1 file changed, 36 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt
index 38802b5..c0a418c 100644
--- a/Documentation/devicetree/bindings/mfd/da9062.txt
+++ b/Documentation/devicetree/bindings/mfd/da9062.txt
@@ -1,22 +1,39 @@
* Dialog DA9062 Power Management Integrated Circuit (PMIC)
-DA9062 consists of a large and varied group of sub-devices:
+Product information for the DA9062 and DA9061 devices can be found here:
+- http://www.dialog-semiconductor.com/products/da9062
+- http://www.dialog-semiconductor.com/products/da9061
+
+The DA9062 PMIC consists of:
Device Supply Names Description
------ ------------ -----------
da9062-regulator : : LDOs & BUCKs
da9062-rtc : : Real-Time Clock
+da9062-onkey : : On Key
+da9062-watchdog : : Watchdog Timer
+da9062-thermal : : Thermal
+
+The DA9061 PMIC consists of:
+
+Device Supply Names Description
+------ ------------ -----------
+da9062-regulator : : LDOs & BUCKs
+da9062-onkey : : On Key
da9062-watchdog : : Watchdog Timer
+da9062-thermal : : Thermal
======
Required properties:
-- compatible : Should be "dlg,da9062".
+- compatible : Should be
+ "dlg,da9062" for DA9062
+ "dlg,da9061" for DA9061
- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
modified to match the chip's OTP settings).
- interrupt-parent : Specifies the reference to the interrupt controller for
- the DA9062.
+ the DA9062 or DA9061.
- interrupts : IRQ line information.
- interrupt-controller
@@ -25,8 +42,8 @@ further information on IRQ bindings.
Sub-nodes:
-- regulators : This node defines the settings for the LDOs and BUCKs. The
- DA9062 regulators are bound using their names listed below:
+- regulators : This node defines the settings for the LDOs and BUCKs.
+ The DA9062 regulators are bound using their names listed below:
buck1 : BUCK_1
buck2 : BUCK_2
@@ -37,19 +54,29 @@ Sub-nodes:
ldo3 : LDO_3
ldo4 : LDO_4
+ The DA9061 regulators are bound using their names listed below:
+
+ buck1 : BUCK_1
+ buck2 : BUCK_2
+ buck3 : BUCK_3
+ ldo1 : LDO_1
+ ldo2 : LDO_2
+ ldo3 : LDO_3
+ ldo4 : LDO_4
+
The component follows the standard regulator framework and the bindings
details of individual regulator device can be found in:
Documentation/devicetree/bindings/regulator/regulator.txt
-
- rtc : This node defines settings required for the Real-Time Clock associated
with the DA9062. There are currently no entries in this binding, however
compatible = "dlg,da9062-rtc" should be added if a node is created.
-- watchdog: This node defines the settings for the watchdog driver associated
- with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be added
- if a node is created.
+- onkey : See ../input/da9062-onkey.txt
+
+- watchdog: See ../watchdog/da9062-watchdog.txt
+- thermal : See ../thermal/da9062-thermal.txt
Example:
@@ -64,10 +91,6 @@ Example:
compatible = "dlg,da9062-rtc";
};
- watchdog {
- compatible = "dlg,da9062-watchdog";
- };
-
regulators {
DA9062_BUCK1: buck1 {
regulator-name = "BUCK1";
--
end-of-patch for PATCH V6
--
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 related
* [PATCH V6 1/7] Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
From: Steve Twiss @ 2017-03-27 9:51 UTC (permalink / raw)
To: DEVICETREE, Guenter Roeck, LINUX-KERNEL, LINUX-WATCHDOG,
Mark Rutland, Rob Herring, Wim Van Sebroeck
Cc: Dmitry Torokhov, Eduardo Valentin, LINUX-INPUT, LINUX-PM,
Lee Jones, Liam Girdwood, Mark Brown, Support Opensource,
Zhang Rui
In-Reply-To: <cover.1490608293.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
Add binding information for DA9062 and DA9061 watchdog.
Example bindings for both DA9062 and DA9061 devices are added. For
the DA9061 device, a fallback compatible line is added as a valid
combination of compatible strings.
The original binding for DA9062 (only) used to reside inside the
Documentation/devicetree/bindings/mfd/da9062.txt MFD document.
The da9062-watchdog section was deleted in that file and replaced
with a link to the new DA9061/62 binding information stored in this
patch.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.11-rc3
v5 -> v6
- NO CODE CHANGE
- Rebased from v4.9 to v4.11-rc3
v4 -> v5
- NO CODE CHANGE
- Rebased from v4.8 to v4.9
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 2/9] to [PATCH V4 1/8]
- Added Acked-by Rob Herring
v2 -> v3
- Patch renamed from [PATCH V1 02/10] to [PATCH V3 2/9]
- Each compatible line should be a valid combination of compatible
strings, alter DA9061 line to include the fall back compatible string
- Update the commit message to describe this change
- Add information about associated patches from this set without
describing them as being explicitly dependent on this binding
v1 -> v2
- Patch renamed from [PATCH V1 07/10] to [PATCH V2 02/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Updated the patch description to be explicit about where parts of
this binding had originally been stored
- A second example for DA9061 is provided to highlight the use of a
fall-back compatible option for the DA9062 watchdog driver
Hi,
No code changes for this version PATCH V5.
As previously:
For the watchdog case: the DA9062 device driver is compatible with the
DA9061 and for this reason there is minimal change required to the DA9062
watchdog device driver. The example for the DA9061 watchdog shows the
use of a fall-back compatible string.
Other information:
The device driver from this patch set (associated with this binding) is
[PATCH V5 6/8] watchdog: da9061: watchdog driver
Regards,
Steve Twiss, Dialog Semiconductor
.../devicetree/bindings/watchdog/da9062-wdt.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
new file mode 100644
index 0000000..b935b52
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
@@ -0,0 +1,23 @@
+* Dialog Semiconductor DA9062/61 Watchdog Timer
+
+Required properties:
+
+- compatible: should be one of the following valid compatible string lines:
+ "dlg,da9061-watchdog", "dlg,da9062-watchdog"
+ "dlg,da9062-watchdog"
+
+Example: DA9062
+
+ pmic0: da9062@58 {
+ watchdog {
+ compatible = "dlg,da9062-watchdog";
+ };
+ };
+
+Example: DA9061 using a fall-back compatible for the DA9062 watchdog driver
+
+ pmic0: da9061@58 {
+ watchdog {
+ compatible = "dlg,da9061-watchdog", "dlg,da9062-watchdog";
+ };
+ };
--
end-of-patch for PATCH V6
^ permalink raw reply related
* Re: [PATCH v2 4/7] pinctrl: armada-37xx: Add gpio support
From: Gregory CLEMENT @ 2017-03-27 9:46 UTC (permalink / raw)
To: Linus Walleij
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, linux-gpio@vger.kernel.org, Rob Herring,
Neta Zur Hershkovits, Victor Gu, Hua Jing, Marcin Wojtas,
Wilson Ding, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <CACRpkdaueEJKTJq6QihyBS18wgtgqVLHAFa=13_2X8AYuh7tqg@mail.gmail.com>
Hi Linus,
On lun., mars 27 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Mar 21, 2017 at 7:28 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>
> You should add something to your Kconfig including:
>
> select GPIOLIB
> select OF_GPIO
>
> or so... or depends on. You certainly need them.
I missed it I will do it in v4.
>
>> +static int armada_37xx_gpiochip_register(struct platform_device *pdev,
>> + struct armada_37xx_pinctrl *info)
>> +{
>> + struct device_node *np;
>> + struct gpio_chip *gc;
>> + int ret = -ENODEV;
>> +
>> + for_each_child_of_node(info->dev->of_node, np) {
>> + if (of_find_property(np, "gpio-controller", NULL)) {
>> + ret = 0;
>> + break;
>> + }
>> + };
>
> OK so several GPIO chips as subnodes, why not one device per
> chip? Or have we discussed this before? It seems a bit weird,
> apparently there is just one node with a gpio-controller, as you're
> just adding one pin range.
As you probably noticed pinctrl and gpio register are mixed in this
hardware. One of the register is alos use to get some clock freqeuncy,
so that's why I ended with a syscon node. The parent node is the
pinctrl. My main motivation to use a subnode was to be ablee to have a
phandle associated with the GPIO chip. In my first version I only have
one node but then I realized that I could not use GPIO in the device
tree without an phandle to point it.
If you have an other solution, I would be happy to remove this subnode.
>
> What happens if there would be two gpio-controllers? The second
> is just ignored without error?
There won't be a second gpio-controllers because we only have one gpio
controller by pin controller (as they are actually the same). Also as I
said above, the subnode is mainly here to provide a phandle.
But I can add a comment to emphasize it.
>
>> + ret = gpiochip_add_data(gc, info);
>> + if (ret)
>> + return ret;
>
> Can't you use devm_gpiochip_add_data()?
I think I can.
>
>> + ret = gpiochip_add_pin_range(&info->gpio_chip, dev_name(dev), 0,
>> + pinbase, info->data->nr_pins);
>> + if (ret)
>> + return ret;
>
> Why can't you put the range(s) into the device tree?
>
> We already have code in drivers/gpio/gpiolib-of.c to do this
> for you. And generic range definition bindings.
It was done in the v3.
Tanks,
Gregory
>
> Yours,
> Linus Walleij
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 6/6] dt-bindings: document rockchip rk3328-evb board
From: cl @ 2017-03-27 9:46 UTC (permalink / raw)
To: heiko
Cc: mark.rutland, wsa, linux-iio, catalin.marinas, shawn.lin,
will.deacon, kever.yang, dianders, yamada.masahiro, tony.xie,
linux-i2c, pmeerw, lars, zhengxing, khilman, linux-rockchip,
jay.xu, Liang Chen, wxt, huangtao, devicetree, zhangqing,
paweljarosz3691, arnd, yhx, knaack.h, robh+dt, matthias.bgg,
rocky.hao, linux-arm-kernel, linux-kernel, david.wu,
fabio.estevam, andy.yan, akpm, shawnguo
In-Reply-To: <1490607650-18650-1-git-send-email-cl@rock-chips.com>
From: Liang Chen <cl@rock-chips.com>
Use "rockchip,rk3328-evb" compatible string for Rockchip RK3328
evaluation board.
Signed-off-by: Liang Chen <cl@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/rockchip.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index cc4ace6..17611cd 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -141,3 +141,7 @@ Rockchip platforms device tree bindings
- Tronsmart Orion R68 Meta
Required root node properties:
- compatible = "tronsmart,orion-r68-meta", "rockchip,rk3368";
+
+- Rockchip RK3328 evb:
+ Required root node properties:
+ - compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
--
1.9.1
^ permalink raw reply related
* [PATCH v5 24/24] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP
From: Kishon Vijay Abraham I @ 2017-03-27 9:45 UTC (permalink / raw)
To: Bjorn Helgaas, Joao Pinto, linux-pci, linux-doc, linux-kernel,
devicetree, linux-omap, linux-arm-kernel
Cc: hch, nsekhar, kishon
In-Reply-To: <20170327094520.3129-1-kishon@ti.com>
The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should
be set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO
in RC mode. However in EP mode, the host system is not able to access the
MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c b/arch/arm/mach-omap2/clockdomains7xx_data.c
index 6c679659cda5..67ebff829cf2 100644
--- a/arch/arm/mach-omap2/clockdomains7xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -524,7 +524,7 @@ static struct clockdomain pcie_7xx_clkdm = {
.dep_bit = DRA7XX_PCIE_STATDEP_SHIFT,
.wkdep_srcs = pcie_wkup_sleep_deps,
.sleepdep_srcs = pcie_wkup_sleep_deps,
- .flags = CLKDM_CAN_HWSUP_SWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
static struct clockdomain atl_7xx_clkdm = {
--
2.11.0
^ permalink raw reply related
* [PATCH v5 23/24] MAINTAINERS: add PCI EP maintainer
From: Kishon Vijay Abraham I @ 2017-03-27 9:45 UTC (permalink / raw)
To: Bjorn Helgaas, Joao Pinto, linux-pci, linux-doc, linux-kernel,
devicetree, linux-omap, linux-arm-kernel
Cc: hch, nsekhar, kishon
In-Reply-To: <20170327094520.3129-1-kishon@ti.com>
Add maintainer for the newly introduced PCI EP framework.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c265a5fe4848..3c1b947811e2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9581,6 +9581,15 @@ F: include/linux/pci*
F: arch/x86/pci/
F: arch/x86/kernel/quirks.c
+PCI EP SUBSYSTEM
+M: Kishon Vijay Abraham I <kishon@ti.com>
+L: linux-pci@vger.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/kishon/pci-endpoint.git
+S: Supported
+F: drivers/pci/endpoint/
+F: drivers/misc/pci_endpoint_test.c
+F: tools/pci/
+
PCI DRIVER FOR ALTERA PCIE IP
M: Ley Foon Tan <lftan@altera.com>
L: rfi@lists.rocketboards.org (moderated for non-subscribers)
--
2.11.0
^ 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