* Re: [PATCH v8 2/2] leds: lm3601x: Introduce the lm3601x LED driver
From: Andy Shevchenko @ 2018-05-22 20:34 UTC (permalink / raw)
To: Dan Murphy
Cc: Rob Herring, Mark Rutland, Jacek Anaszewski, devicetree,
Linux Kernel Mailing List, Linux LED Subsystem
In-Reply-To: <dca52e6e-451c-2ca4-a001-867708622d7b@ti.com>
On Tue, May 22, 2018 at 11:26 PM, Dan Murphy <dmurphy@ti.com> wrote:
> On 05/22/2018 03:12 PM, Andy Shevchenko wrote:
>> On Tue, May 22, 2018 at 5:24 PM, Dan Murphy <dmurphy@ti.com> wrote:
>>> +static struct lm3601x_led *fled_cdev_to_led(
>>> + struct led_classdev_flash *fled_cdev)
>>
>> Didn't notice before. This will look much better in one line.
>
> Gives LTL warning.
I wouldn't really care about it.
But I leave to Jacek to decide.
After addressing the rest, FWIW,
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 2/2] drivers: soc: Add LLCC driver
From: rishabhb @ 2018-05-22 20:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-arm Mailing List, linux-arm-msm, devicetree,
Linux Kernel Mailing List, linux-arm, tsoni, ckadabi, Evan Green,
Rob Herring
In-Reply-To: <CAHp75Vd8HZU+BT38-OfXHiihv1yZG6YBeMWyfweBA+kAwk6HUw@mail.gmail.com>
On 2018-05-22 12:38, Andy Shevchenko wrote:
> On Tue, May 22, 2018 at 9:33 PM, <rishabhb@codeaurora.org> wrote:
>> On 2018-05-18 14:01, Andy Shevchenko wrote:
>>> On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar
>>> <rishabhb@codeaurora.org> wrote:
>
>>>> +#define ACTIVATE 0x1
>>>> +#define DEACTIVATE 0x2
>>>> +#define ACT_CTRL_OPCODE_ACTIVATE 0x1
>>>> +#define ACT_CTRL_OPCODE_DEACTIVATE 0x2
>>>> +#define ACT_CTRL_ACT_TRIG 0x1
>>>
>>>
>>> Are these bits? Perhaps BIT() ?
>>>
>> isn't it just better to use fixed size as u suggest in the next
>> comment?
>
> If the are bits, use BIT() macro.
>
>>>> +struct llcc_slice_desc *llcc_slice_getd(u32 uid)
>>>> +{
>>>> + const struct llcc_slice_config *cfg;
>>>> + struct llcc_slice_desc *desc;
>>>> + u32 sz, count = 0;
>>>> +
>>>> + cfg = drv_data->cfg;
>>>> + sz = drv_data->cfg_size;
>>>> +
>>>
>>>
>>>> + while (cfg && count < sz) {
>>>> + if (cfg->usecase_id == uid)
>>>> + break;
>>>> + cfg++;
>>>> + count++;
>>>> + }
>>>> + if (cfg == NULL || count == sz)
>>>> + return ERR_PTR(-ENODEV);
>>>
>>>
>>> if (!cfg)
>>> return ERR_PTR(-ENODEV);
>>>
>>> while (cfg->... != uid) {
>>> cfg++;
>>> count++;
>>> }
>>>
>>> if (count == sz)
>>> return ...
>>>
>>> Though I would rather put it to for () loop.
>>>
>> In each while loop iteration the cfg pointer needs to be checked for
>> NULL. What if the usecase id never matches the uid passed by client
>> and we keep iterating. At some point it will crash.
>
> do {
> if (!cfg || count == sz)
> return ...(-ENODEV);
> ...
> } while (...);
>
> Though, as I said for-loop will look slightly better I think.
Is this fine?
for (count = 0; count < sz; count++) {
if (!cfg)
return ERR_PTR(-ENODEV);
if (cfg->usecase_id == uid)
break;
cfg++;
}
if (count == sz)
return ERR_PTR(-ENODEV);
>
>>>> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
>>>> + DEACTIVATE);
>>>
>>>
>>> Perhaps one line (~83 characters here is OK) ?
>>
>> The checkpatch script complains about such lines.
>
> So what if it just 3 characters out?
>
Other reviewers sometimes are not okay if the checkpatch complains.
Because I have gotten many reviews previously concerning about line
length. Not sure how to proceed here.
>>>> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
>>>> + ACTIVATE);
>
>>> Ditto.
>
>>>> + attr1_cfg = bcast_off +
>>>> +
>>>> LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
>>>> + attr0_cfg = bcast_off +
>>>> +
>>>> LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
>
>>> Ditto.
>
>>>> + attr1_val |= llcc_table[i].probe_target_ways <<
>>>> + ATTR1_PROBE_TARGET_WAYS_SHIFT;
>>>> + attr1_val |= llcc_table[i].fixed_size <<
>>>> + ATTR1_FIXED_SIZE_SHIFT;
>>>> + attr1_val |= llcc_table[i].priority <<
>>>> ATTR1_PRIORITY_SHIFT;
>
>>> foo |=
>>> bar << SHIFT;
>>>
>>> would look slightly better.
>
> Did you consider this option ?
Yes, forgot to mention.
^ permalink raw reply
* Re: [PATCH v7 2/2] drivers: soc: Add LLCC driver
From: Andy Shevchenko @ 2018-05-22 20:46 UTC (permalink / raw)
To: Rishabh Bhatnagar
Cc: linux-arm Mailing List, linux-arm-msm, devicetree,
Linux Kernel Mailing List, linux-arm, tsoni, ckadabi, Evan Green,
Rob Herring
In-Reply-To: <19968f96da0c548dd7d96e7520ce899e@codeaurora.org>
On Tue, May 22, 2018 at 11:40 PM, <rishabhb@codeaurora.org> wrote:
> On 2018-05-22 12:38, Andy Shevchenko wrote:
>> On Tue, May 22, 2018 at 9:33 PM, <rishabhb@codeaurora.org> wrote:
>>> On 2018-05-18 14:01, Andy Shevchenko wrote:
>>>>> +struct llcc_slice_desc *llcc_slice_getd(u32 uid)
>>>>> +{
>>>>> + const struct llcc_slice_config *cfg;
>>>>> + struct llcc_slice_desc *desc;
>>>>> + u32 sz, count = 0;
>>>>> +
>>>>> + cfg = drv_data->cfg;
>>>>> + sz = drv_data->cfg_size;
>>>>> +
>>>>
>>>>
>>>>
>>>>> + while (cfg && count < sz) {
>>>>> + if (cfg->usecase_id == uid)
>>>>> + break;
>>>>> + cfg++;
>>>>> + count++;
>>>>> + }
>>>>> + if (cfg == NULL || count == sz)
>>>>> + return ERR_PTR(-ENODEV);
>>>> if (!cfg)
>>>> return ERR_PTR(-ENODEV);
>>>>
>>>> while (cfg->... != uid) {
>>>> cfg++;
>>>> count++;
>>>> }
>>>>
>>>> if (count == sz)
>>>> return ...
>>>>
>>>> Though I would rather put it to for () loop.
>>>>
>>> In each while loop iteration the cfg pointer needs to be checked for
>>> NULL. What if the usecase id never matches the uid passed by client
>>> and we keep iterating. At some point it will crash.
>> do {
>> if (!cfg || count == sz)
>> return ...(-ENODEV);
>> ...
>> } while (...);
>>
>> Though, as I said for-loop will look slightly better I think.
>
> Is this fine?
> for (count = 0; count < sz; count++) {
> if (!cfg)
> return ERR_PTR(-ENODEV);
> if (cfg->usecase_id == uid)
> break;
> cfg++;
> }
> if (count == sz)
> return ERR_PTR(-ENODEV);
for (count = 0; cfg && count < sz; count++, cfg++)
if (_id == uid)
break;
if (!cfg || count == sz)
return ERR_PTR(-ENODEV);
Simpler ?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net-next v2 1/7] net: dsa: qca8k: Add QCA8334 binding documentation
From: Michal @ 2018-05-22 20:50 UTC (permalink / raw)
To: Rob Herring
Cc: netdev, linux-kernel, devicetree, f.fainelli, vivien.didelot,
andrew, mark.rutland, davem, michal.vokac
In-Reply-To: <20180522194039.GA15413@rob-hp-laptop>
On 22.5.2018 21:40, Rob Herring wrote:
> On Tue, May 22, 2018 at 01:16:26PM +0200, Michal Vokáč wrote:
>> Add support for the four-port variant of the Qualcomm QCA833x switch.
>>
>> The CPU port default link settings can be reconfigured using
>> a fixed-link sub-node.
>>
>> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
>> ---
>> Changes in v2:
>> - Add commit message and document fixed-link binding.
>>
>> .../devicetree/bindings/net/dsa/qca8k.txt | 23 +++++++++++++++++++++-
>> 1 file changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
>> index 9c67ee4..15b9057 100644
>> --- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt
>> +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
>> @@ -2,7 +2,10 @@
>>
>> Required properties:
>>
>> -- compatible: should be "qca,qca8337"
>> +- compatible: should be one of:
>> + "qca,qca8334"
>> + "qca,qca8337"
>> +
>> - #size-cells: must be 0
>> - #address-cells: must be 1
>>
>> @@ -14,6 +17,20 @@ port and PHY id, each subnode describing a port needs to have a valid phandle
>> referencing the internal PHY connected to it. The CPU port of this switch is
>> always port 0.
>>
>> +A CPU port node has the following optional property:
>
> s/property/node/
>
> Otherwise,
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Good catch, I will correct this.
Thanks for the review Rob.
Michal
^ permalink raw reply
* Re: [PATCH v8 2/2] leds: lm3601x: Introduce the lm3601x LED driver
From: Jacek Anaszewski @ 2018-05-22 20:53 UTC (permalink / raw)
To: Dan Murphy, robh+dt, mark.rutland, andy.shevchenko
Cc: devicetree, linux-kernel, linux-leds
In-Reply-To: <20180522142417.19639-2-dmurphy@ti.com>
Hi Dan,
In three cases we should have "strobe" instead of "flash"
Please refer to the code below.
Otherwise it looks good to me - you even fixed some earlier
unnoticed issues.
On 05/22/2018 04:24 PM, Dan Murphy wrote:
> Introduce the family of LED devices that can
> drive a torch, strobe or IR LED.
>
> The LED driver can be configured with a strobe
> timer to execute a strobe flash. The IR LED
> brightness is controlled via the torch brightness
> register.
>
> The data sheet for each the LM36010 and LM36011
> LED drivers can be found here:
> http://www.ti.com/product/LM36010
> http://www.ti.com/product/LM36011
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v8 - Removed OF Kconfig dependency, change strobe to flash, updated label generation,
> fixed brightness calculation, added mutex_destroy and flash_unregister - https://patchwork.kernel.org/patch/10416163/
>
> v7 - Numerous fixes to many to list. Highlights are moved from OF APIs to device_property
> APIs, updated LED registration, timeout to reg algorithim, and fixed label generation -
> https://patchwork.kernel.org/patch/10401437/
> v6 - This driver has been heavily modified from v5. There is no longer reading
> of individual child nodes. There are too many changes to list here see -
> https://patchwork.kernel.org/patch/10392123/
> v5 - Fixed magic numbers, change reg cache type, added of_put_node to release
> the dt node ref, and I did not change the remove function to leave the LED in its
> state on driver removal - https://patchwork.kernel.org/patch/10391741/
> v4 - Fixed Cocci issue using ARRAY_SIZE - https://patchwork.kernel.org/patch/10389259/
> v3 - removed wildcard dt compatible, fixed copyright, fixed struct doc, removed
> RO registers from default, added regmap volatile for FLAGS_REG, updated regmap cache type,
> fixed unlock and extra semi colon in strobe_set, removed unnecessary out label
> in led register and fixed checking of the ret in brightness_set - https://patchwork.kernel.org/patch/10386243/
> v2 - Fixed kbuild issue and removed unused cdev_strobe - https://patchwork.kernel.org/patch/10384585/
>
>
> drivers/leds/Kconfig | 9 +
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-lm3601x.c | 492 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 502 insertions(+)
> create mode 100644 drivers/leds/leds-lm3601x.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 2c896c0e69e1..d95d436e6089 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -145,6 +145,15 @@ config LEDS_LM3692X
> This option enables support for the TI LM3692x family
> of white LED string drivers used for backlighting.
>
> +config LEDS_LM3601X
> + tristate "LED support for LM3601x Chips"
> + depends on LEDS_CLASS && I2C
> + depends on LEDS_CLASS_FLASH
> + select REGMAP_I2C
> + help
> + This option enables support for the TI LM3601x family
> + of flash, torch and indicator classes.
> +
> config LEDS_LOCOMO
> tristate "LED Support for Locomo device"
> depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 91eca81cae82..b79807fe1b67 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
> obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
> obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
> obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
> +obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o
>
> # LED SPI Drivers
> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
> diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c
> new file mode 100644
> index 000000000000..b1f0ede704c1
> --- /dev/null
> +++ b/drivers/leds/leds-lm3601x.c
> @@ -0,0 +1,492 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Flash and torch driver for Texas Instruments LM3601X LED
> +// Flash driver chip family
> +// Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
> +
> +#include <linux/delay.h>
> +#include <linux/i2c.h>
> +#include <linux/leds.h>
> +#include <linux/led-class-flash.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <uapi/linux/uleds.h>
> +
> +#define LM3601X_LED_IR 0x0
> +#define LM3601X_LED_TORCH 0x1
> +
> +/* Registers */
> +#define LM3601X_ENABLE_REG 0x01
> +#define LM3601X_CFG_REG 0x02
> +#define LM3601X_LED_FLASH_REG 0x03
> +#define LM3601X_LED_TORCH_REG 0x04
> +#define LM3601X_FLAGS_REG 0x05
> +#define LM3601X_DEV_ID_REG 0x06
> +
> +#define LM3601X_SW_RESET BIT(7)
> +
> +/* Enable Mode bits */
> +#define LM3601X_MODE_STANDBY 0x00
> +#define LM3601X_MODE_IR_DRV BIT(0)
> +#define LM3601X_MODE_TORCH BIT(1)
> +#define LM3601X_MODE_STROBE (BIT(0) | BIT(1))
> +#define LM3601X_STRB_EN BIT(2)
> +#define LM3601X_STRB_EDGE_TRIG BIT(3)
> +#define LM3601X_IVFM_EN BIT(4)
> +
> +#define LM36010_BOOST_LIMIT_28 BIT(5)
> +#define LM36010_BOOST_FREQ_4MHZ BIT(6)
> +#define LM36010_BOOST_MODE_PASS BIT(7)
> +
> +/* Flag Mask */
> +#define LM3601X_FLASH_TIME_OUT BIT(0)
> +#define LM3601X_UVLO_FAULT BIT(1)
> +#define LM3601X_THERM_SHUTDOWN BIT(2)
> +#define LM3601X_THERM_CURR BIT(3)
> +#define LM36010_CURR_LIMIT BIT(4)
> +#define LM3601X_SHORT_FAULT BIT(5)
> +#define LM3601X_IVFM_TRIP BIT(6)
> +#define LM36010_OVP_FAULT BIT(7)
> +
> +#define LM3601X_MAX_TORCH_I_UA 376000
> +#define LM3601X_MIN_TORCH_I_UA 2400
> +#define LM3601X_TORCH_REG_DIV 2965
> +
> +#define LM3601X_MAX_STROBE_I_UA 1500000
> +#define LM3601X_MIN_STROBE_I_UA 11000
> +#define LM3601X_STROBE_REG_DIV 11800
> +
> +#define LM3601X_TIMEOUT_MASK 0x1e
> +#define LM3601X_ENABLE_MASK (LM3601X_MODE_IR_DRV | LM3601X_MODE_TORCH)
> +
> +#define LM3601X_LOWER_STEP_US 40000
> +#define LM3601X_UPPER_STEP_US 200000
> +#define LM3601X_MIN_TIMEOUT_US 40000
> +#define LM3601X_MAX_TIMEOUT_US 1600000
> +#define LM3601X_TIMEOUT_XOVER_US 400000
> +
> +enum lm3601x_type {
> + CHIP_LM36010 = 0,
> + CHIP_LM36011,
> +};
> +
> +/**
> + * struct lm3601x_led -
> + * @fled_cdev: flash LED class device pointer
> + * @client: Pointer to the I2C client
> + * @regmap: Devices register map
> + * @lock: Lock for reading/writing the device
> + * @led_name: LED label for the Torch or IR LED
> + * @flash_timeout: the timeout for the flash
> + * @last_flag: last known flags register value
> + * @torch_current_max: maximum current for the torch
> + * @flash_current_max: maximum current for the flash
> + * @max_flash_timeout: maximum timeout for the flash
> + * @led_mode: The mode to enable either IR or Torch
> + */
> +struct lm3601x_led {
> + struct led_classdev_flash fled_cdev;
> + struct i2c_client *client;
> + struct regmap *regmap;
> + struct mutex lock;
> +
> + char led_name[LED_MAX_NAME_SIZE];
> +
> + unsigned int flash_timeout;
> + unsigned int last_flag;
> +
> + u32 torch_current_max;
> + u32 flash_current_max;
> + u32 max_flash_timeout;
> +
> + u32 led_mode;
> +};
> +
> +static const struct reg_default lm3601x_regmap_defs[] = {
> + { LM3601X_ENABLE_REG, 0x20 },
> + { LM3601X_CFG_REG, 0x15 },
> + { LM3601X_LED_FLASH_REG, 0x00 },
> + { LM3601X_LED_TORCH_REG, 0x00 },
> +};
> +
> +static bool lm3601x_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case LM3601X_FLAGS_REG:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static const struct regmap_config lm3601x_regmap = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +
> + .max_register = LM3601X_DEV_ID_REG,
> + .reg_defaults = lm3601x_regmap_defs,
> + .num_reg_defaults = ARRAY_SIZE(lm3601x_regmap_defs),
> + .cache_type = REGCACHE_RBTREE,
> + .volatile_reg = lm3601x_volatile_reg,
> +};
> +
> +static struct lm3601x_led *fled_cdev_to_led(
> + struct led_classdev_flash *fled_cdev)
> +{
> + return container_of(fled_cdev, struct lm3601x_led, fled_cdev);
> +}
> +
> +static int lm3601x_read_faults(struct lm3601x_led *led)
> +{
> + int flags_val;
> + int ret;
> +
> + ret = regmap_read(led->regmap, LM3601X_FLAGS_REG, &flags_val);
> + if (ret < 0)
> + return -EIO;
> +
> + led->last_flag = 0;
> +
> + if (flags_val & LM36010_OVP_FAULT)
> + led->last_flag |= LED_FAULT_OVER_VOLTAGE;
> +
> + if (flags_val & (LM3601X_THERM_SHUTDOWN | LM3601X_THERM_CURR))
> + led->last_flag |= LED_FAULT_OVER_TEMPERATURE;
> +
> + if (flags_val & LM3601X_SHORT_FAULT)
> + led->last_flag |= LED_FAULT_SHORT_CIRCUIT;
> +
> + if (flags_val & LM36010_CURR_LIMIT)
> + led->last_flag |= LED_FAULT_OVER_CURRENT;
> +
> + if (flags_val & LM3601X_UVLO_FAULT)
> + led->last_flag |= LED_FAULT_UNDER_VOLTAGE;
> +
> + if (flags_val & LM3601X_IVFM_TRIP)
> + led->last_flag |= LED_FAULT_INPUT_VOLTAGE;
> +
> + if (flags_val & LM3601X_THERM_SHUTDOWN)
> + led->last_flag |= LED_FAULT_LED_OVER_TEMPERATURE;
> +
> + return led->last_flag;
> +}
> +
> +static int lm3601x_brightness_set(struct led_classdev *cdev,
> + enum led_brightness brightness)
> +{
> + struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(cdev);
> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
> + int ret, led_mode_val;
> +
> + mutex_lock(&led->lock);
> +
> + ret = lm3601x_read_faults(led);
> + if (ret < 0)
> + goto out;
> +
> + if (led->led_mode == LM3601X_LED_TORCH)
> + led_mode_val = LM3601X_MODE_TORCH;
> + else
> + led_mode_val = LM3601X_MODE_IR_DRV;
> +
> + if (brightness == LED_OFF) {
> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
> + led_mode_val, LED_OFF);
> + goto out;
> + }
> +
> + ret = regmap_write(led->regmap, LM3601X_LED_TORCH_REG, brightness);
> + if (ret < 0)
> + goto out;
> +
> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
> + LM3601X_MODE_TORCH | LM3601X_MODE_IR_DRV,
> + led_mode_val);
> +out:
> + mutex_unlock(&led->lock);
> + return ret;
> +}
> +
> +static int lm3601x_flash_set(struct led_classdev_flash *fled_cdev,
> + bool state)
> +{
> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
> + int timeout_reg_val = 0;
> + int current_timeout;
> + int ret;
> +
> + mutex_lock(&led->lock);
> +
> + ret = regmap_read(led->regmap, LM3601X_CFG_REG, ¤t_timeout);
> + if (ret < 0)
> + goto out;
> +
> + if (led->flash_timeout >= LM3601X_TIMEOUT_XOVER_US)
> + timeout_reg_val = led->flash_timeout / LM3601X_UPPER_STEP_US + 0x07;
> + else
> + timeout_reg_val = led->flash_timeout / LM3601X_LOWER_STEP_US - 0x01;
> +
> + if (led->flash_timeout != current_timeout)
> + ret = regmap_update_bits(led->regmap, LM3601X_CFG_REG,
> + LM3601X_TIMEOUT_MASK, timeout_reg_val);
> +
> + if (state)
> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
> + LM3601X_MODE_TORCH | LM3601X_MODE_IR_DRV,
> + LM3601X_MODE_STROBE);
> + else
> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
> + LM3601X_MODE_STROBE, LED_OFF);
> +
> + ret = lm3601x_read_faults(led);
> +out:
> + mutex_unlock(&led->lock);
> + return ret;
> +}
> +
> +static int lm3601x_flash_brightness_set(struct led_classdev_flash *fled_cdev,
> + u32 brightness)
> +{
> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
> + int ret;
> + u8 brightness_val;
> +
> + mutex_lock(&led->lock);
> + ret = lm3601x_read_faults(led);
> + if (ret < 0)
> + goto out;
> +
> + if (brightness == LED_OFF) {
> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
> + LM3601X_MODE_STROBE, LED_OFF);
> + goto out;
> + }
> +
> + brightness_val = brightness / LM3601X_STROBE_REG_DIV;
> +
> + ret = regmap_write(led->regmap, LM3601X_LED_FLASH_REG, brightness_val);
> +out:
> + mutex_unlock(&led->lock);
> + return ret;
> +}
> +
> +static int lm3601x_flash_timeout_set(struct led_classdev_flash *fled_cdev,
> + u32 timeout)
> +{
> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
> + int ret = 0;
> +
> + mutex_lock(&led->lock);
> +
> + led->flash_timeout = timeout;
> +
> + mutex_unlock(&led->lock);
> +
> + return ret;
> +}
> +
> +static int lm3601x_flash_get(struct led_classdev_flash *fled_cdev,
> + bool *state)
> +{
> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
> + int ret;
> + int flash_state;
s/flash_state/strobe_state/
> +
> + mutex_lock(&led->lock);
> +
> + ret = regmap_read(led->regmap, LM3601X_ENABLE_REG, &flash_state);
> + if (ret < 0)
> + goto out;
> +
> + *state = flash_state & LM3601X_MODE_STROBE;
> +
> +out:
> + mutex_unlock(&led->lock);
> + return ret;
> +}
> +
> +static int lm3601x_flash_fault_get(struct led_classdev_flash *fled_cdev,
> + u32 *fault)
> +{
> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
> +
> + lm3601x_read_faults(led);
> +
> + *fault = led->last_flag;
> +
> + return 0;
> +}
> +
> +static const struct led_flash_ops flash_ops = {
> + .flash_brightness_set = lm3601x_flash_brightness_set,
> + .strobe_set = lm3601x_flash_set,
> + .strobe_get = lm3601x_flash_get,
In case of the above two functions let's stay by "strobe".
I.e.: lm3601x_strobe_set and lm3601x_strobe_get.
> + .timeout_set = lm3601x_flash_timeout_set,
> + .fault_get = lm3601x_flash_fault_get,
> +};
> +
> +static int lm3601x_register_leds(struct lm3601x_led *led)
> +{
> + struct led_classdev *led_cdev;
> + struct led_flash_setting *setting;
> +
> + led->fled_cdev.ops = &flash_ops;
> +
> + setting = &led->fled_cdev.timeout;
> + setting->min = LM3601X_MIN_TIMEOUT_US;
> + setting->max = led->max_flash_timeout;
> + setting->step = LM3601X_LOWER_STEP_US;
> + setting->val = led->max_flash_timeout;
> +
> + setting = &led->fled_cdev.brightness;
> + setting->min = LM3601X_MIN_STROBE_I_UA;
> + setting->max = led->flash_current_max;
> + setting->step = LM3601X_TORCH_REG_DIV;
> + setting->val = led->flash_current_max;
> +
> + led_cdev = &led->fled_cdev.led_cdev;
> + led_cdev->name = led->led_name;
> + led_cdev->brightness_set_blocking = lm3601x_brightness_set;
> + led_cdev->max_brightness = DIV_ROUND_UP(led->torch_current_max,
> + LM3601X_TORCH_REG_DIV);
> + led_cdev->flags |= LED_DEV_CAP_FLASH;
> +
> + return led_classdev_flash_register(&led->client->dev, &led->fled_cdev);
> +}
> +
> +static int lm3601x_parse_node(struct lm3601x_led *led,
> + struct device_node *node)
> +{
> + struct fwnode_handle *child = NULL;
> + int ret = -ENODEV;
> + const char *name;
> +
> + child = device_get_next_child_node(&led->client->dev, child);
> + if (!child) {
> + dev_err(&led->client->dev, "No LED Child node\n");
> + return ret;
> + }
> +
> + ret = fwnode_property_read_u32(child, "reg", &led->led_mode);
> + if (ret) {
> + dev_err(&led->client->dev, "reg DT property missing\n");
> + goto out_err;
> + }
> +
> + if (led->led_mode > LM3601X_LED_TORCH ||
> + led->led_mode < LM3601X_LED_IR) {
> + dev_warn(&led->client->dev, "Invalid led mode requested\n");
> + ret = -EINVAL;
> + goto out_err;
> + }
> +
> + ret = fwnode_property_read_string(child, "label", &name);
> + if (ret) {
> + if (led->led_mode == LM3601X_LED_TORCH)
> + name = "torch";
> + else
> + name = "infrared";
> + }
> +
> + snprintf(led->led_name, sizeof(led->led_name),
> + "%s:%s", led->client->name, name);
> +
> + ret = fwnode_property_read_u32(child, "led-max-microamp",
> + &led->torch_current_max);
> + if (ret < 0) {
> + dev_warn(&led->client->dev,
> + "led-max-microamp DT property missing\n");
> + goto out_err;
> + }
> +
> + ret = fwnode_property_read_u32(child, "flash-max-microamp",
> + &led->flash_current_max);
> + if (ret < 0) {
> + dev_warn(&led->client->dev,
> + "flash-max-microamp DT property missing\n");
> + goto out_err;
> + }
> +
> + ret = fwnode_property_read_u32(child, "flash-max-timeout-us",
> + &led->max_flash_timeout);
> + if (ret < 0) {
> + dev_warn(&led->client->dev,
> + "flash-max-timeout-us DT property missing\n");
> + goto out_err;
> + }
> +
> +out_err:
> + fwnode_handle_put(child);
> + return ret;
> +}
> +
> +static int lm3601x_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct lm3601x_led *led;
> + int err;
> +
> + led = devm_kzalloc(&client->dev, sizeof(*led), GFP_KERNEL);
> + if (!led)
> + return -ENOMEM;
> +
> + led->client = client;
> + i2c_set_clientdata(client, led);
> +
> + err = lm3601x_parse_node(led, client->dev.of_node);
> + if (err < 0)
> + return -ENODEV;
> +
> + led->regmap = devm_regmap_init_i2c(client, &lm3601x_regmap);
> + if (IS_ERR(led->regmap)) {
> + err = PTR_ERR(led->regmap);
> + dev_err(&client->dev,
> + "Failed to allocate register map: %d\n", err);
> + return err;
> + }
> +
> + mutex_init(&led->lock);
> +
> + return lm3601x_register_leds(led);
> +}
> +
> +static int lm3601x_remove(struct i2c_client *client)
> +{
> + struct lm3601x_led *led = i2c_get_clientdata(client);
> +
> + led_classdev_flash_unregister(&led->fled_cdev);
> + mutex_destroy(&led->lock);
> +
> + return regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
> + LM3601X_ENABLE_MASK,
> + LM3601X_MODE_STANDBY);
> +}
> +
> +static const struct i2c_device_id lm3601x_id[] = {
> + { "LM36010", CHIP_LM36010 },
> + { "LM36011", CHIP_LM36011 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, lm3601x_id);
> +
> +static const struct of_device_id of_lm3601x_leds_match[] = {
> + { .compatible = "ti,lm36010", },
> + { .compatible = "ti,lm36011", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, of_lm3601x_leds_match);
> +
> +static struct i2c_driver lm3601x_i2c_driver = {
> + .driver = {
> + .name = "lm3601x",
> + .of_match_table = of_lm3601x_leds_match,
> + },
> + .probe = lm3601x_probe,
> + .remove = lm3601x_remove,
> + .id_table = lm3601x_id,
> +};
> +module_i2c_driver(lm3601x_i2c_driver);
> +
> +MODULE_DESCRIPTION("Texas Instruments Flash Lighting driver for LM3601X");
> +MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
> +MODULE_LICENSE("GPL v2");
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: adc: Add DT binding document for PMIC5 ADC
From: Rob Herring @ 2018-05-22 20:54 UTC (permalink / raw)
To: Siddartha Mohanadoss
Cc: Jonathan Cameron, linux-iio, devicetree, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, cdevired, rphani,
sivaa
In-Reply-To: <18857b67-0865-7794-d981-87beb3f9c22f@codeaurora.org>
On Tue, May 15, 2018 at 04:57:03PM -0700, Siddartha Mohanadoss wrote:
> Hi Jonathan,
>
> Thanks for the comments.
>
>
> On 05/12/2018 03:15 AM, Jonathan Cameron wrote:
> > On Tue, 8 May 2018 14:38:21 -0700
> > Siddartha Mohanadoss <smohanad@codeaurora.org> wrote:
> >
> > > PMIC5 ADC has support for clients to measure voltage and current
> > > on inputs connected to the PMIC. Clients include reading voltage
> > > phone power and on board system thermistors for thermal management.
> > > ADC5 on certain PMIC has support to read battery current.
> > >
> > > This change adds documentation.
> > >
> > > Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
> > Hi Siddartha,
> >
> > Some complexity in here! Anyhow, a few comments inline and we will definitely
> > be wanting guidance from the devicetree people for this one.
> >
> > Jonathan
> >
> > > ---
> > > .../devicetree/bindings/iio/adc/qcom,spmi-adc5.txt | 137 +++++++++++++++++++++
> > > 1 file changed, 137 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,spmi-adc5.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-adc5.txt b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-adc5.txt
> > > new file mode 100644
> > > index 0000000..c9268ba
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-adc5.txt
> > > @@ -0,0 +1,137 @@
> > > +Qualcomm Technologies Inc. SPMI PMIC5 voltage and current ADC
> > > +
> > > +SPMI PMIC5 voltage ADC (ADC) provides interface to clients to read
> > > +voltage. The VADC is a 16-bit sigma-delta ADC.
> > > +
> > > +ADC node:
> > > +
> > > +- compatible:
> > > + Usage: required
> > > + Value type: <string>
> > > + Definition: Should contain "qcom,spmi-adc5" for PMIC5 ADC driver.
> > > + Should contain "qcom,spmi-adc-rev2" for PMIC refresh ADC driver.
Chip specific compatible strings please unless you convince me there are
a large number of chips per above compatible.
Bindings are for hardware, not drivers.
> > > +
> > > +- reg:
> > > + Usage: required
> > > + Value type: <prop-encoded-array>
> > > + Definition: VADC base address and length in the SPMI PMIC register map.
> > > +
> > > +- #address-cells:
> > > + Usage: required
> > > + Value type: <u32>
> > > + Definition: Must be one. Child node 'reg' property should define ADC
> > > + channel number.
> > > +
> > > +- #size-cells:
> > > + Usage: required
> > > + Value type: <u32>
> > > + Definition: Must be zero.
> > > +
> > > +- #io-channel-cells:
> > > + Usage: required
> > > + Value type: <u32>
> > > + Definition: Must be one. For details about IIO bindings see:
> > > + Documentation/devicetree/bindings/iio/iio-bindings.txt
> > > +
> > > +- interrupts:
> > > + Usage: optional
> > > + Value type: <prop-encoded-array>
> > > + Definition: End of conversion interrupt.
> > > +
> > > +Channel node properties:
> > > +
> > > +- reg:
> > > + Usage: required
> > > + Value type: <u32>
> > > + Definition: ADC channel number.
> > > + See include/dt-bindings/iio/qcom,spmi-vadc.h
> > > +
> > > +- label:
> > > + Usage: required
> > > + Value type: <empty>
> > > + Definition: ADC datasheet channel name.
> > > + For thermistor inputs connected to generic AMUX or GPIO inputs
> > > + these can vary across platform for the same pins. Hence select
> > > + the datasheet name for this channel.
Why do you need this? If the name comes from a datasheet list, then
perhaps you should list the exact string here. Otherwise, there's a lot
left to the user in terms of capitalization, etc.
> > > +
> > > +- qcom,pre-scaling:
> > > + Usage: required
> > > + Value type: <u32 array>
> > > + Definition: Used for scaling the channel input signal before the signal is
> > > + fed to VADC. The configuration for this node is to know the
> > > + pre-determined ratio and use it for post scaling. Select one from
> > > + the following options.
> > > + <1 1>, <1 3>, <1 4>, <1 6>, <1 20>, <1 8>, <10 81>, <1 10>
> > > + If property is not found default value depending on chip will be used.
> > > +
> > > +- qcom,decimation:
> > > + Usage: optional
> > > + Value type: <u32>
> > > + Definition: This parameter is used to decrease ADC sampling rate.
> > > + Quicker measurements can be made by reducing decimation ratio.
> > > + For PMIC5 ADC, combined two step decimation values are 250, 420 and 840.
> > > + If property is not found, default value of 840 will be used.
> > The odd indenting here needs sorting. Mixture of spaces and tabs at the moment.
> Ok, will take a look.
> > Hmm. In someways this is a policy decision so should be pushed up to userspace,
> > but given the 'right' value will be somewhat dependent on what you are doing
> > with the channel and what is wired to it, it could arguably have a 'right' value
> > for a given circuit. This is really just the sampling frequency wrapped
> > up in decimation of something, I'm guessing some input clock?
> Yes. It's number of samples collected over a 4.8MHz clock.
> The only reason to update this value would be if client wants to get
> the conversion results back sooner. Hence left this as an optional property.
> >
> > Let's see what the Device-tree people think on this one! Personally I have
> > never really minded devicetree providing sensible defaults. We can put
> > control on these things later, if there is a usecase for changing them.
I don't have a problem with this in DT, though my first thought was it
should be common. Then after reading some on decimation, I'm not sure it
would always just be a single 32-bit value?
> >
> > > + For PMIC refresh ADC, supported decimation values are 256, 512, 1024.
> > > + If property is not found, default value of 1024 will be used.
> > > +
> > > +- qcom,ratiometric:
> > > + Usage: optional
> > > + Value type: <empty>
> > > + Definition: Channel calibration type. If this property is specified
> > > + VADC will use the VDD reference (1.875V) and GND for channel
> > > + calibration. If property is not found, channel will be
> > > + calibrated with 0V and 1.25V reference channels, also
> > > + known as absolute calibration.
> > > +
> > > +- qcom,hw-settle-time:
> > > + Usage: optional
> > > + Value type: <u32>
> > > + Definition: Time between AMUX getting configured and the ADC starting
> > > + conversion.
> > > + For PMIC5, delay = 15us for value 0,
> > > + 100us * (value) for values 0 < value < 11, and
> > > + 2ms * (value - 10) otherwise.
> > > + Valid values are: 15, 100, 200, 300, 400, 500, 600, 700, 800,
> > This description is very confusing given the different uses of 'value'
> > None of the values you have allowed is less than 11 so the first condition
> > doesn't apply.
> The 'value' is an index programmed in the hardware to achieve the
> hardware settling delay specified under valid values. I will update the
> documentation here.
> >
> > > + 900 us and 1, 2, 4, 6, 8, 10 ms
> > > + If property is not found, channel will use 15us.
> > > + For PMIC rev2, delay = 100us * (value) for values 0 < value < 11, and
> > > + 2ms * (value - 10) otherwise.
> > > + Valid values are: 0, 100, 200, 300, 400, 500, 600, 700, 800,
> > > + 900 us and 1, 2, 4, 6, 8, 10 ms
> > > + If property is not found, channel will use 0 us.
> > > +
> > > +- qcom,avg-samples:
> > > + Usage: optional
> > > + Value type: <u32>
> > > + Definition: Number of samples to be used for measurement.
> > > + Averaging provides the option to obtain a single measurement
> > > + from the ADC that is an average of multiple samples. The value
> > > + selected is 2^(value).
> > > + Valid values are: 1, 2, 4, 8, 16
> > > + If property is not found, 1 sample will be used.
> > As with decimation, this is arguably not a feature of the hardware, but
> > a software decision...
We already have a common property for touchscreens and vendor properties
for a few ADCs, so we should define a common one.
Now, sadly, I've just found that all these properties are already
defined in bindings/iio/adc/qcom,spmi-vadc.txt. Why didn't you add these
compatibles to the existing binding. Then we're not reviewing the same
thing again...
Rob
^ permalink raw reply
* Re: [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Guenter Roeck @ 2018-05-22 20:54 UTC (permalink / raw)
To: Ray Jui
Cc: Wim Van Sebroeck, Rob Herring, Mark Rutland, Frank Rowand,
Catalin Marinas, Will Deacon, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list
In-Reply-To: <1527014840-21236-4-git-send-email-ray.jui@broadcom.com>
On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:
> If the watchdog hardware is already enabled during the boot process,
> when the Linux watchdog driver loads, it should reset the watchdog and
> tell the watchdog framework. As a result, ping can be generated from
> the watchdog framework, until the userspace watchdog daemon takes over
> control
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> ---
> drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
> index 1484609..408ffbe 100644
> --- a/drivers/watchdog/sp805_wdt.c
> +++ b/drivers/watchdog/sp805_wdt.c
> @@ -42,6 +42,7 @@
> /* control register masks */
> #define INT_ENABLE (1 << 0)
> #define RESET_ENABLE (1 << 1)
> + #define ENABLE_MASK (INT_ENABLE | RESET_ENABLE)
> #define WDTINTCLR 0x00C
> #define WDTRIS 0x010
> #define WDTMIS 0x014
> @@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
> MODULE_PARM_DESC(nowayout,
> "Set to 1 to keep watchdog running after device release");
>
> +/* returns true if wdt is running; otherwise returns false */
> +static bool wdt_is_running(struct watchdog_device *wdd)
> +{
> + struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> + if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
> + ENABLE_MASK)
> + return true;
> + else
> + return false;
return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
> +}
> +
> /* This routine finds load value that will reset system in required timout */
> static int wdt_setload(struct watchdog_device *wdd, unsigned int timeout)
> {
> @@ -239,6 +252,15 @@ sp805_wdt_probe(struct amba_device *adev, const struct amba_id *id)
> watchdog_init_timeout(&wdt->wdd, 0, &adev->dev);
> wdt_setload(&wdt->wdd, wdt->wdd.timeout);
>
> + /*
> + * If HW is already running, enable/reset the wdt and set the running
> + * bit to tell the wdt subsystem
> + */
> + if (wdt_is_running(&wdt->wdd)) {
> + wdt_enable(&wdt->wdd);
> + set_bit(WDOG_HW_RUNNING, &wdt->wdd.status);
> + }
> +
> ret = watchdog_register_device(&wdt->wdd);
> if (ret) {
> dev_err(&adev->dev, "watchdog_register_device() failed: %d\n",
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH 1/5] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Guenter Roeck @ 2018-05-22 20:56 UTC (permalink / raw)
To: Ray Jui
Cc: Wim Van Sebroeck, Rob Herring, Mark Rutland, Frank Rowand,
Catalin Marinas, Will Deacon, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list
In-Reply-To: <1527014840-21236-2-git-send-email-ray.jui@broadcom.com>
On Tue, May 22, 2018 at 11:47:16AM -0700, Ray Jui wrote:
> Update the SP805 binding document to add optional 'timeout-sec'
> devicetree property
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Documentation/devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> index edc4f0e..f898a86 100644
> --- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> @@ -19,6 +19,8 @@ Required properties:
>
> Optional properties:
> - interrupts : Should specify WDT interrupt number.
> +- timeout-sec : Should specify default WDT timeout in seconds. If unset, the
> + default timeout is 30 seconds
>
> Examples:
>
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH 2/2] iio: adc: Add Qualcomm SPMI PMIC5 ADC driver
From: Rob Herring @ 2018-05-22 20:57 UTC (permalink / raw)
To: Siddartha Mohanadoss
Cc: Jonathan Cameron, linux-iio, linux-arm-msm, devicetree,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
cdevired, rphani, sivaa
In-Reply-To: <1525815536-27781-1-git-send-email-smohanad@codeaurora.org>
On Tue, May 08, 2018 at 02:38:56PM -0700, Siddartha Mohanadoss wrote:
> This patch adds support for Qualcomm SPMI PMIC5 family
> of ADC driver that supports hardware based offset and
> gain compensation. The ADC peripheral can measure both
> voltage and current channels whose input signal is
> connected to the PMIC.
>
> The register set and configuration has been refreshed
> compared to the prior Qualcomm PMIC ADC family. Register
> ADC5 as part of the IIO framework.
>
> Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
> ---
> drivers/iio/adc/Kconfig | 18 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/qcom-spmi-adc5.c | 818 +++++++++++++++++++++++++++++++
> drivers/iio/adc/qcom-vadc-common.c | 241 +++++++++
> drivers/iio/adc/qcom-vadc-common.h | 51 ++
> include/dt-bindings/iio/qcom,spmi-vadc.h | 115 ++++-
This belongs in the binding patch.
> 6 files changed, 1243 insertions(+), 1 deletion(-)
> create mode 100644 drivers/iio/adc/qcom-spmi-adc5.c
^ permalink raw reply
* Re: [PATCH 2/5] watchdog: sp805: add 'timeout-sec' DT property support
From: Guenter Roeck @ 2018-05-22 20:57 UTC (permalink / raw)
To: Ray Jui
Cc: Wim Van Sebroeck, Rob Herring, Mark Rutland, Frank Rowand,
Catalin Marinas, Will Deacon, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list
In-Reply-To: <1527014840-21236-3-git-send-email-ray.jui@broadcom.com>
On Tue, May 22, 2018 at 11:47:17AM -0700, Ray Jui wrote:
> Add support for optional devicetree property 'timeout-sec'.
> 'timeout-sec' is used in the driver if specified in devicetree.
> Otherwise, fall back to driver default, i.e., 60 seconds
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/watchdog/sp805_wdt.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
> index 03805bc..1484609 100644
> --- a/drivers/watchdog/sp805_wdt.c
> +++ b/drivers/watchdog/sp805_wdt.c
> @@ -230,7 +230,14 @@ sp805_wdt_probe(struct amba_device *adev, const struct amba_id *id)
> spin_lock_init(&wdt->lock);
> watchdog_set_nowayout(&wdt->wdd, nowayout);
> watchdog_set_drvdata(&wdt->wdd, wdt);
> - wdt_setload(&wdt->wdd, DEFAULT_TIMEOUT);
> +
> + /*
> + * If 'timeout-sec' devicetree property is specified, use that.
> + * Otherwise, use DEFAULT_TIMEOUT
> + */
> + wdt->wdd.timeout = DEFAULT_TIMEOUT;
> + watchdog_init_timeout(&wdt->wdd, 0, &adev->dev);
> + wdt_setload(&wdt->wdd, wdt->wdd.timeout);
>
> ret = watchdog_register_device(&wdt->wdd);
> if (ret) {
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH] media: rcar-vin: Drop unnecessary register properties from example vin port
From: Rob Herring @ 2018-05-22 20:57 UTC (permalink / raw)
To: Simon Horman
Cc: Mark Rutland, devicetree, Magnus Damm, linux-renesas-soc,
Geert Uytterhoeven, Niklas Söderlund, Mauro Carvalho Chehab,
linux-arm-kernel, linux-media
In-Reply-To: <20180509184558.14960-1-horms+renesas@verge.net.au>
On Wed, May 09, 2018 at 08:45:58PM +0200, Simon Horman wrote:
> The example vin port node does not have an address and thus does not
> need address-cells or address size-properties.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 3 ---
> 1 file changed, 3 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 2/2] leds: lm3601x: Introduce the lm3601x LED driver
From: Jacek Anaszewski @ 2018-05-22 20:58 UTC (permalink / raw)
To: Andy Shevchenko, Dan Murphy
Cc: Rob Herring, Mark Rutland, devicetree, Linux Kernel Mailing List,
Linux LED Subsystem
In-Reply-To: <CAHp75Vdg9HTyQhv1KMOCqq5FjgPAC2q015Opnh3jDWvZY2bbNQ@mail.gmail.com>
On 05/22/2018 10:34 PM, Andy Shevchenko wrote:
> On Tue, May 22, 2018 at 11:26 PM, Dan Murphy <dmurphy@ti.com> wrote:
>> On 05/22/2018 03:12 PM, Andy Shevchenko wrote:
>>> On Tue, May 22, 2018 at 5:24 PM, Dan Murphy <dmurphy@ti.com> wrote:
>
>
>>>> +static struct lm3601x_led *fled_cdev_to_led(
>>>> + struct led_classdev_flash *fled_cdev)
>>>
>>> Didn't notice before. This will look much better in one line.
>>
>> Gives LTL warning.
>
> I wouldn't really care about it.
> But I leave to Jacek to decide.
Please make it one line.
It is even Linus' recommendation to not strictly stick to the
80 character limit as we all have modern computers nowadays.
> After addressing the rest, FWIW,
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: Revisiting Devicetree Overlay Manager
From: Frank Rowand @ 2018-05-22 21:13 UTC (permalink / raw)
To: Alan Tull
Cc: Manivannan Sadhasivam, Rob Herring, Grant Likely,
Pantelis Antoniou, dimitrysh, john.stultz, nicolas.dechesne,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
daniel.thompson, loic.poulain
In-Reply-To: <CANk1AXQ5kyFCp9YcJ6L7n=Ub4EcKYmbiYXZYzSO_17RHgpPn5g@mail.gmail.com>
On 05/22/18 12:32, Alan Tull wrote:
> On Thu, May 17, 2018 at 10:53 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> Hi Manivannan,
>>
>> On 04/25/18 10:26, Frank Rowand wrote:
>>> Hi Manivannan,
>>>
>>> Sorry for the delay. I'll try to get to this today or tommorrow.
>>>
>>> -Frank
>>
>> Sorry for the even longer than expected delay. As I mentioned to you
>> off-list (bad Frank!), I wanted to pull together a lot of my disparate
>> thoughts on overlays before responding to your specific proposal and
>> questions. The first (of probably many versions) of that write up
>> is at:
>>
>> https://elinux.org/Frank%27s_Evolving_Overlay_Thoughts
>
> Slightly off topic (sorry), but you could move "FPGAs programmed after
> kernel begins execution" to what has been completed since it's
> implemented in drivers/fpga/of-fpga-region.c. The remaining issue for
Thanks for the suggestion. I copied that to the completed section, but
also left it in current location because the current location is creating
a list of use cases. I clarified that items on the list of use cases could
already be implemented.
The use of overlays by FPGAs still face many of the issues that need to be
resolved. As a random example, not judging whether the issue is important:
consistency of /proc/device-tree/ as an overlay is being applied or removed.
-Frank
> that use is adding some kind of acceptable userspace interface, that
> seems to be captured in "overlay manager" in the "issues and what
> needs to be completed" section.
>
>>
>> My thoughts on some of your questions are addressed on that page.
>> I still need to read through your questions because there are
>> probably several that I did not address on that page.
>>
>> -Frank
>>
>>>
>>>
>>> On 04/25/18 00:34, Manivannan Sadhasivam wrote:
>>>> Hi Frank,
>>>>
>>>> Did you had time to look into this? Especially I'd like to hear your
>>>> opinion on the first pain point I have mentioned. I can understand
>>>> that the whole point on introducing the of_overlay_fdt_apply() API
>>>> is to remove the duplication of overlay FDT unflattening, but do you have
>>>> any idea of how we can make this API work with overlay nodes appended
>>>> to the base DTB?
>>>>
>>>> Thanks,
>>>> Mani
>>>>
>>>> On Thu, Apr 19, 2018 at 08:08:04PM +0530, Manivannan Sadhasivam wrote:
>>>>> Hello Everyone,
>>>>>
>>>>> I have just started working on the Devicetree Overlay Manager support in
>>>>> kernel. The idea is to merge overlays at boot time specified via some
>>>>> interface like kernel command line. The motivation for this work comes from
>>>>> Overlay Manager [1] submitted by John last year. The mechanism which I have
>>>>> been working on is an extension to John's work. It focusses on addressing
>>>>> Rob's comments on the Overlay Manager which involves having multiple ways
>>>>> to load overlays.
>>>>>
>>>>> Proposal:
>>>>> =========
>>>>>
>>>>> 1. Pass all devicetree overlays via following methods:
>>>>> - Overlays appended to base DTB
>>>>> - Individual overlays built into kernel as firmware blobs
>>>>> - Any other ways?
>
> Would an interface that allows applying/removing overlays after boot
> time work for you? I'm referring to something like Pantelis' ConfigFS
> interface which has been proposed (and currently rejected). I
> understand your proposal is on the kernel command line, but I am
> wondering whether something like that could work for both our uses.
> My use is applying overlays after the kernel has booted to reprogram a
> FPGA and add nodes for the devices that show up in the FPGA (and
> removing the overlays to prepare for reprogramming).
>
> Alan
>
>>>>>
>>>>> 2. Specify overlays to load via kernel command line as below:
>>>>> - overlay_mgr.overlays=<overlay1,overlay2,...>
>>>>>
>>>>> 3. Merge only the specified overlays during boot time. First look for the
>>>>> overlay in the base DTB. If it is found, just apply it, else defer to firmware
>>>>> load approach.
>>>>>
>>>>> The Overlay Manager code is expected to be very simple and will just do the
>>>>> above mentioned work. Later on, it will be extended to support dynamic
>>>>> modification of overlays from userspace with some additional security
>>>>> features like having a property listed in the base devicetree for only
>>>>> allowing changes to the current node and its child nodes, etc...
>>>>>
>>>>> Pain Points:
>>>>> ============
>>>>>
>>>>> 1. Starting from 4.17 we don't have any API exposed from DT core to merge
>>>>> individual devicetree nodes. We only have of_overlay_fdt_apply() function
>>>>> which takes the whole FDT. This will work very well for the firmware approach
>>>>> since we will pass the overlays blobs but not for overlays appended to base DTB,
>>>>> where we will pass individual overlay nodes.
>>>>>
>>>>> 2. Using firmware load method will force us to have this Overlay Manager code
>>>>> at late_initcall level since firmware class exists only in fs_inticall level,
>>>>> which might be too late for some devices.
>>>>>
>>>>> 3. This whole approach is not expected to work very well (still not yet tested)
>>>>> on DSI based devices since it needs to be present at very early during boot
>>>>> process.
>>>>>
>>>>> The Overlay Manager propsed here will be board agnostic and it should work on
>>>>> all platforms supporting DT. This will be a _very_ useful feature for the
>>>>> development boards such as 96Boards, Raspberry Pi, BBB etc... and also for
>>>>> production ready devices.
>>>>>
>>>>> So, I'd like to hear suggestions/feedbacks for the above mentioned proposal &
>>>>> pain points and hope to land the most awaited feature in kernel.
>>>>>
>>>>> Regards,
>>>>> Mani
>>>>>
>>>>> [1] https://lkml.org/lkml/2017/10/10/20
>>>>
>>>
>>> .
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [linux-next PATCH 0/4] Enable network driver on K2G ICE and GP EVMs
From: Murali Karicheri @ 2018-05-22 21:28 UTC (permalink / raw)
To: santosh.shilimkar@oracle.com, ssantosh, robh+dt, mark.rutland,
linux, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <8e1aa492-ae7a-de2b-f5d2-8756b10ece79@oracle.com>
On 05/20/2018 11:17 PM, santosh.shilimkar@oracle.com wrote:
> On 5/11/18 12:29 PM, Murali Karicheri wrote:
>> Now that NetCP driver patches for K2G SoC is merged to linux-next master
>> this series add patches to enable network driver on K2G ICE and GP EVMs.
>>
>> Thanks
>>
>> Applied the patches on top of latest linux-next master, built kernel and
>> booted up on both EVMs. The logs are below
>>
>> K2G GP EVM: https://pastebin.ubuntu.com/p/ycZDnZXYPx/
>> K2G ICE EVM: https://pastebin.ubuntu.com/p/bdCpzgdrXr/
>>
>> Murali Karicheri (4):
>> ARM: dts: k2g: add dt bindings to support network driver
>> ARM: dts: keystone-k2g-evm: Enable netcp network driver
>> ARM: dts: keystone-k2g-ice: Enable netcp network driver
>> ARM: keystone: k2g: enable micrel and dp83867 phys
>>
>> arch/arm/boot/dts/keystone-k2g-evm.dts | 53 +++++++++++
>> arch/arm/boot/dts/keystone-k2g-ice.dts | 59 ++++++++++++
>> arch/arm/boot/dts/keystone-k2g-netcp.dtsi | 147 ++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/keystone-k2g.dtsi | 13 +++
>> arch/arm/configs/keystone_defconfig | 2 +
>> 5 files changed, 274 insertions(+)
>> create mode 100644 arch/arm/boot/dts/keystone-k2g-netcp.dtsi
>>
> Looks good. Will add this to the queue for 4.19. Thanks !!
>
> Regards,
> Santosh
>
Thanks Santosh!
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Re: [PATCH 2/9] ARM: dts: lager: Drop MTD partitioning from DT
From: Marek Vasut @ 2018-05-22 21:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wolfram Sang, Linux-Renesas, Laurent Pinchart,
Simon Horman, Linux ARM, Marek Vasut
In-Reply-To: <CAMuHMdV1TFH_QwTv4fsOGnUOCNftC9369_1AQmZDK+NBLDmw-Q@mail.gmail.com>
On 05/22/2018 04:32 PM, Geert Uytterhoeven wrote:
> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> Drop the MTD partitioning from DT, since it does not describe HW
>> and to give way to a more flexible kernel command line partition
>> passing.
>>
>> To retain the original partitioning, assure you have enabled
>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
>> following to your kernel command line:
>>
>> mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
>
> I guess s/4096k/4m/ works, too?
Yes, but all the other boards use nnn k, so let's stick with k . I don't
want one value to stick out like a sore thumb.
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH net-next v2 2/7] net: dsa: qca8k: Add support for QCA8334 switch'
From: Andrew Lunn @ 2018-05-22 21:58 UTC (permalink / raw)
To: Michal Vokáč, '
Cc: netdev, linux-kernel, devicetree, f.fainelli, vivien.didelot,
mark.rutland, robh+dt, davem, michal.vokac
In-Reply-To: <1526987792-56861-3-git-send-email-michal.vokac@ysoft.com>
On Tue, May 22, 2018 at 01:16:27PM +0200, Michal Vokáč wrote:
> Add support for the four-port variant of the Qualcomm QCA833x switch.
>
> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 1/7] net: dsa: qca8k: Add QCA8334 binding documentation
From: Andrew Lunn @ 2018-05-22 21:58 UTC (permalink / raw)
To: Michal Vokáč
Cc: netdev, linux-kernel, devicetree, f.fainelli, vivien.didelot,
mark.rutland, robh+dt, davem, michal.vokac
In-Reply-To: <1526987792-56861-2-git-send-email-michal.vokac@ysoft.com>
On Tue, May 22, 2018 at 01:16:26PM +0200, Michal Vokáč wrote:
> Add support for the four-port variant of the Qualcomm QCA833x switch.
>
> The CPU port default link settings can be reconfigured using
> a fixed-link sub-node.
>
> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
From: Marek Vasut @ 2018-05-22 22:01 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wolfram Sang, Richard Weinberger,
Linux-Renesas, Boris Brezillon, Laurent Pinchart, Simon Horman,
Linux ARM, Marek Vasut
In-Reply-To: <CAMuHMdXRnoyhNz=3v_=ZCV=FWX4TwKqx7MpH0g3c7GwtXKP1tg@mail.gmail.com>
On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> Drop the MTD partitioning from DT, since it does not describe HW
>> and to give way to a more flexible kernel command line partition
>> passing.
>>
>> To retain the original partitioning, assure you have enabled
>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
>> following to your kernel command line:
>>
>> mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
>
> I think the "@0" can be dropped, as it's optional?
> 4m?
My take on this is that the loader is actually at offset 0x0 of the MTD
device and we explicitly state that in the mtdparts to anchor the first
partition within the MTD device and all the other partitions are at
offset +(sum of the sizes of all partitions listed before the current
one) relative to that first partition.
Removing the @0 feels fragile at best and it seems to depend on the
current behavior of the code.
> (Gaining more knowledge during reviewing ;-)
>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 1/2] soc: bcm: brcmstb: pm: Add support for newer rev B3.0 controllers
From: Rob Herring @ 2018-05-22 22:30 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-arm-kernel, Doug Berger, Mark Rutland, Brian Norris,
Gregory Fong, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
Justin Chen,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20180511220242.837-2-f.fainelli@gmail.com>
On Fri, May 11, 2018 at 03:02:41PM -0700, Florian Fainelli wrote:
> From: Doug Berger <opendmb@gmail.com>
>
> Update the Device Tree binding document and add a matching entry for the
> MEMC DDR controller revision B3.0 which is found on chips like 7278A0
> and newer.
>
> Signed-off-by: Doug Berger <opendmb@gmail.com>
> [florian: tweak commit message, make it apply to upstream kernel]
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 1 +
> drivers/soc/bcm/brcmstb/pm/pm-arm.c | 4 ++++
> 2 files changed, 5 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
Side note: this should really move out of bindings/arm/ to
bindings/memory-controllers/ or at least to its own file.
Rob
^ permalink raw reply
* Re: [PATCH 2/2] soc: bcm: brcmstb: Add missing DDR MEMC compatible strings
From: Rob Herring @ 2018-05-22 22:31 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-arm-kernel, Mark Rutland, Brian Norris, Gregory Fong,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Doug Berger,
Justin Chen,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20180511220242.837-3-f.fainelli@gmail.com>
On Fri, May 11, 2018 at 03:02:42PM -0700, Florian Fainelli wrote:
> We would not be matching the following chip/compatible strings
> combinations, which would lead to not setting the warm boot flag
> correctly, fix that:
>
> 7260A0/B0: brcm,brcmstb-memc-ddr-rev-b.2.1
> 7255A0: brcm,brcmstb-memc-ddr-rev-b.2.3
> 7278Bx: brcm,brcmstb-memc-ddr-rev-b.3.1
>
> The B2.1 core (which is in 7260 A0 and B0) doesn't have the
> SHIMPHY_ADDR_CNTL_0_DDR_PAD_CNTRL setup in the memsys init code, nor
> does it have the warm boot flag re-definition on entry. Those changes
> were for B2.2 and later MEMSYS cores. Fall back to the previous S2/S3
> entry method for these specific chips.
>
> Fixes: 0b741b8234c8 ("soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 3 +++
> drivers/soc/bcm/brcmstb/pm/pm-arm.c | 12 ++++++++++++
> 2 files changed, 15 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] clk: rockchip: remove deprecated gate-clk code and dt-binding
From: Rob Herring @ 2018-05-22 22:33 UTC (permalink / raw)
To: Heiko Stuebner
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
sboyd-DgEjT+Ai2ygdnm+yROfE0A, mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180512143038.30447-1-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
On Sat, May 12, 2018 at 04:30:38PM +0200, Heiko Stuebner wrote:
> Initially we tried modeling clocks via the devicetree before switching
> to clocks declared in the clock drivers and only exporting specific
> ids to the devicetree.
>
> As the old code was in the kernel for 1-2 releases when the new mode
> of operation was added we kept it for backwards compatibility.
>
> That deprecation notice is in the binding since july 2014, so nearly
> 4 years now and I think it's time to drop the old cruft.
>
> Especially as at the time using the mainline kernel on Rockchip devices
> was not really possible, except for experiments on the really old socs of
> the rk3066 + rk3188 line, so there shouldn't be any devicetrees still
> around that rely on that code.
>
> Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
> ---
> .../devicetree/bindings/clock/rockchip.txt | 77 ---------------
> drivers/clk/rockchip/Makefile | 1 -
> drivers/clk/rockchip/clk-rockchip.c | 98 -------------------
> 3 files changed, 176 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/rockchip.txt
> delete mode 100644 drivers/clk/rockchip/clk-rockchip.c
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH] remoteproc: Add APSS based Qualcomm ADSP PIL driver for SDM845
From: Rob Herring @ 2018-05-22 22:33 UTC (permalink / raw)
To: Rohit kumar
Cc: ohad, bjorn.andersson, mark.rutland, linux-remoteproc, devicetree,
linux-kernel, bgoswami, sbpata, asishb, rkarra,
RajendraBabu Medisetti, Krishnamurthy Renu
In-Reply-To: <1526194908-19027-1-git-send-email-rohitkr@codeaurora.org>
On Sun, May 13, 2018 at 12:31:48PM +0530, Rohit kumar wrote:
> This adds Qualcomm ADSP PIL driver support for SDM845 with ADSP bootup
> and shutdown operation handled from Application Processor SubSystem(APSS).
>
> Signed-off-by: Rohit kumar <rohitkr@codeaurora.org>
> Signed-off-by: RajendraBabu Medisetti <rajendrabm@codeaurora.org>
> Signed-off-by: Krishnamurthy Renu <krishnamurthy.renu@codeaurora.org>
> ---
> .../devicetree/bindings/remoteproc/qcom,adsp.txt | 1 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/remoteproc/Makefile | 3 +-
> drivers/remoteproc/qcom_adsp_pil.c | 122 ++++-----
> drivers/remoteproc/qcom_adsp_pil.h | 86 ++++++
> drivers/remoteproc/qcom_adsp_pil_sdm845.c | 304 +++++++++++++++++++++
> 5 files changed, 454 insertions(+), 62 deletions(-)
> create mode 100644 drivers/remoteproc/qcom_adsp_pil.h
> create mode 100644 drivers/remoteproc/qcom_adsp_pil_sdm845.c
^ permalink raw reply
* Re: [PATCH] media: dt-bindings: media: rcar_vin: add support for r8a77965
From: Rob Herring @ 2018-05-22 22:34 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: devicetree, linux-media, linux-renesas-soc
In-Reply-To: <20180513185818.15359-1-niklas.soderlund+renesas@ragnatech.se>
On Sun, May 13, 2018 at 08:58:18PM +0200, Niklas S�derlund wrote:
> Signed-off-by: Niklas S�derlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1c669eb35..c2c57dcf73f4851b 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -21,6 +21,7 @@ on Gen3 platforms to a CSI-2 receiver.
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7796" for the R8A7796 device
> + - "renesas,vin-r8a77965" for the R8A77965 device
> - "renesas,vin-r8a77970" for the R8A77970 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> device.
> --
> 2.17.0
>
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx51-babbage: Fix USB PHY duplicate unit-address
From: Rob Herring @ 2018-05-22 22:45 UTC (permalink / raw)
To: Shawn Guo; +Cc: Fabio Estevam, devicetree, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20180515080624.GR26863@dragon>
On Tue, May 15, 2018 at 04:06:26PM +0800, Shawn Guo wrote:
> On Mon, May 14, 2018 at 03:29:35PM -0300, Fabio Estevam wrote:
> > From: Fabio Estevam <fabio.estevam@nxp.com>
> >
> > Currently the following DTC warning is seen with W=1:
> >
> > arch/arm/boot/dts/imx51-babbage.dtb: Warning (unique_unit_address): /usbphy/usbphy@0: duplicate unit-address (also used in node /usbphy/usbh1phy@0)
> >
> > Fix it by moving the USB PHY node outside of simple-bus and drop the
> > unneeded unit-address.
> >
> > Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> > ---
> > arch/arm/boot/dts/imx51-babbage.dts | 21 +++++++--------------
> > 1 file changed, 7 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
> > index b8ca73d..de46906 100644
> > --- a/arch/arm/boot/dts/imx51-babbage.dts
> > +++ b/arch/arm/boot/dts/imx51-babbage.dts
> > @@ -170,20 +170,13 @@
> > mux-ext-port = <3>;
> > };
> >
> > - usbphy {
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > - compatible = "simple-bus";
> > -
> > - usbh1phy: usbh1phy@0 {
> > - compatible = "usb-nop-xceiv";
> > - reg = <0>;
> > - clocks = <&clk_usb>;
> > - clock-names = "main_clk";
> > - reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
> > - vcc-supply = <&vusb_reg>;
> > - #phy-cells = <0>;
> > - };
> > + usbh1phy: usbphy1 {
> > + compatible = "usb-nop-xceiv";
> > + clocks = <&clk_usb>;
> > + clock-names = "main_clk";
> > + reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
> > + vcc-supply = <&vusb_reg>;
> > + #phy-cells = <0>;
>
> This should be considered as a whole together with usbphy in imx51.dtsi.
> Also, I would like to get some input from DT folks on how we should name
> the node uniquely. @Rob.
'usbphy1' is fine. I don't have a better suggestion...
Rob
^ permalink raw reply
* Re: [RFC PATCH 02/10] dt-bindings: devfreq: rk3399_dmc: Add rockchip,pmu phandle.
From: Rob Herring @ 2018-05-22 22:45 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Mark Rutland, David Airlie, devicetree, linux-pm, Stephen Boyd,
Michael Turquette, Derek Basehore, Will Deacon, dri-devel,
linux-kernel, Chanwoo Choi, Kyungmin Park, MyungJoo Ham,
linux-rockchip, kernel, linux-clk, linux-arm-kernel, Lin Huang
In-Reply-To: <20180514211610.26618-3-enric.balletbo@collabora.com>
On Mon, May 14, 2018 at 11:16:02PM +0200, Enric Balletbo i Serra wrote:
> The Rockchip DMC (Dynamic Memory Interface) needs to access to the PMU
> general register files to know the DRAM type, so add a phandle to the
> syscon that manages these registers.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>
> Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox