* [RESEND PATCH V7 1/5] Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
From: Steve Twiss @ 2017-04-06 8:28 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.1491467308.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
---
Hi,
I have just noticed.
The driver code changes for the da9062/61 watchdog have been applied to
the linux kernel. The da9062/61 alterations for
drivers/watchdog/da9062_wdt.c appear in linux-stable/v4.10-rc1. Those
changes are linked to this binding patch, but this patch seems to have
been missed out.
The source code dependency for this patch is given in the commit:
72106c1 v4.10-rc1 watchdog: da9062/61: watchdog driver
I don't see anything blocking for merge of this patch now.
Regards,
Steve
This patch applies against linux-next and v4.11-rc3
v6 -> v7
- NO CODE CHANGE
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
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 RESEND PATCH V7
--
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] of: Add vendor prefix for Nordic Semiconductor
From: Kumar Gala @ 2017-04-06 8:29 UTC (permalink / raw)
To: Rob Herring; +Cc: Kumar Gala, Device Tree Mailing List, Mark Rutland
Nordic Semiconductor is a semiconductor company specializing in ARM
Cortex-M based SoCs for low-power wireless communication, especially
Bluetooth.
Signed-off-by: Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ec0bfb9..dd9e7b2 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -212,6 +212,7 @@ newhaven Newhaven Display International
ni National Instruments
nintendo Nintendo
nokia Nokia
+nordic Nordic Semiconductor
nuvoton Nuvoton Technology Corporation
nvd New Vision Display
nvidia NVIDIA
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/3] ARM: dts: rockchip: Add support for phyCORE-RK3288 SoM
From: Heiko Stuebner @ 2017-04-06 8:30 UTC (permalink / raw)
To: Wadim Egorov
Cc: robh+dt, mark.rutland, linux, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <1491214985-18331-1-git-send-email-w.egorov@phytec.de>
Am Montag, 3. April 2017, 12:23:03 CEST schrieb Wadim Egorov:
> The phyCORE-RK3288 is a SoM (System on Module) containing a RK3288 SoC.
> The module can be connected to different carrier boards.
> It can be also equipped with different RAM, SPI flash and eMMC variants.
> The Rapid Development Kit option is using the following setup:
>
> - 1 GB DDR3 RAM (2 Banks)
> - 1x 4 KB EEPROM
> - DP83867 Gigabit Ethernet PHY
> - 16 MB SPI Flash
> - 4 GB eMMC Flash
>
> Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
applied for 4.12 with the following minor changes:
- moved phy-handle property up a bit
- switches compatible and #address+#size-cells in mdio0
- dropped rockchip,grf from &io_domains (grf is a simple-mfd and can
get the grf syscon on its own via its parent)
- vdd_cpu: regulator@60 (from fan53555@60)
- serial_flash: flash@0 (from m25p80@0)
Nodes should be named after their "category" not the actual device
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH v4 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Peter Rosin @ 2017-04-06 8:39 UTC (permalink / raw)
To: michael.hennerich-OyLXuOCK7orQT0dZR+AlfA,
wsa-z923LK4zBo2bacvFa/9K2g, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491397671-14675-2-git-send-email-michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
Hi Michael,
I would still like to hear from someone with more gpio experience.
Anyway, from my point of view, there's just a few minor things left,
with comments inline as usual.
Thanks for you patience!
Cheers,
peda
On 2017-04-05 15:07, michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org wrote:
> From: Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
>
> 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.
>
> Signed-off-by: Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
>
> ---
>
> Changes since v1:
>
> - Sort makefile entries
> - Sort driver includes
> - Use proper defines
> - Miscellaneous coding style fixups
> - Rename mux select callback
> - Revise i2c-mux-idle-disconnect handling
> - Add ENABLE GPIO handling on error and device removal.
> - Remove surplus of_match_device call.
>
> Changes since v2:
>
> - Stop double error reporting (i2c_mux_add_adapter)
> - Change subject
> - Split dt bindings to separate patch
>
> Changes since v3:
>
> - Change subject and add spaces
> - Convert to I2C_MUX_LOCKED
> - Convert to regmap
> - Remove local register cache
> - Restore previous ENABLE GPIO handling
> - Initially pulse ENABLE low
> - Eliminate i2c client struct in driver state structure
> - Simplify error return path
> - Misc minor cleanups
> ---
> MAINTAINERS | 8 +
> drivers/i2c/muxes/Kconfig | 11 ++
> drivers/i2c/muxes/Makefile | 1 +
> drivers/i2c/muxes/i2c-mux-ltc4306.c | 310 ++++++++++++++++++++++++++++++++++++
> 4 files changed, 330 insertions(+)
> create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c
>
> 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-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
> +W: http://ez.analog.com/community/linux-device-drivers
> +L: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.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-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
> M: Cyril Hrubis <chrubis-AlSwsSmVLrQ@public.gmane.org>
> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
> index 10b3d17..41153b4 100644
> --- a/drivers/i2c/muxes/Kconfig
> +++ b/drivers/i2c/muxes/Kconfig
> @@ -30,6 +30,17 @@ 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
> + select REGMAP_I2C
> + help
> + If you say yes here you get support for the LTC LTC4306 or LTC4305
This reads a bit funny, and I think you should just spell out the
first LTC? But perhaps not in the tristate above though, depending
on how long it gets?
> + 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..ff7618c 100644
> --- a/drivers/i2c/muxes/Makefile
> +++ b/drivers/i2c/muxes/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE) += i2c-arb-gpio-challenge.o
> obj-$(CONFIG_I2C_DEMUX_PINCTRL) += i2c-demux-pinctrl.o
>
> obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
> +obj-$(CONFIG_I2C_MUX_LTC4306) += i2c-mux-ltc4306.o
> obj-$(CONFIG_I2C_MUX_MLXCPLD) += i2c-mux-mlxcpld.o
> obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
> obj-$(CONFIG_I2C_MUX_PCA954x) += i2c-mux-pca954x.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..7d34434
> --- /dev/null
> +++ b/drivers/i2c/muxes/i2c-mux-ltc4306.c
> @@ -0,0 +1,310 @@
> +/*
> + * 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/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/i2c-mux.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +#define LTC4305_MAX_NCHANS 2
> +#define LTC4306_MAX_NCHANS 4
> +
> +#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
> +#define LTC_SWITCH_MASK 0xF0
> +
> +enum ltc_type {
> + ltc_4305,
> + ltc_4306,
> +};
> +
> +struct chip_desc {
> + u8 nchans;
> + u8 num_gpios;
> +};
> +
> +struct ltc4306 {
> + struct regmap *regmap;
> + struct gpio_chip gpiochip;
> + const struct chip_desc *chip;
> +};
> +
> +static const struct chip_desc chips[] = {
> + [ltc_4305] = {
> + .nchans = LTC4305_MAX_NCHANS,
> + },
> + [ltc_4306] = {
> + .nchans = LTC4306_MAX_NCHANS,
> + .num_gpios = 2,
> + },
> +};
> +
> +static bool ltc4306_is_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + return (reg == LTC_REG_CONFIG) ? true : false;
> +}
> +
> +static const struct regmap_config ltc4306_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = LTC_REG_SWITCH,
> + .volatile_reg = ltc4306_is_volatile_reg,
> + .cache_type = REGCACHE_RBTREE,
Did you consider REGCACHE_FLAT? There are very few registers and no hole
in the map, and maintaining a tree seems like total overkill.
> +};
> +
> +static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct ltc4306 *data = gpiochip_get_data(chip);
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(data->regmap, LTC_REG_CONFIG, &val);
> + if (ret < 0)
> + return ret;
> +
> + return (val & BIT(1 - offset));
The outer parentheses do not add anything, and I think they might remain
from when you just removed a double negation at some point. But is it
good practice to indicate "high" with anything other than one? Sure, the
gpiolib function that wraps the ->get() op does the !! dance for you,
but even so, every single one of the half dozen random gpio providers I
looked at had code to coerce the value to 0/1 (or error). Which makes me
think you should also have it. And the gpio_chip documentation on ->get()
agrees with me...
> +}
> +
> +static void ltc4306_gpio_set(struct gpio_chip *chip, unsigned int offset,
> + int value)
> +{
> + struct ltc4306 *data = gpiochip_get_data(chip);
> +
> + regmap_update_bits(data->regmap, LTC_REG_CONFIG, BIT(5 - offset),
> + value ? BIT(5 - offset) : 0);
> +}
> +
> +static int ltc4306_gpio_direction_input(struct gpio_chip *chip,
> + unsigned int offset)
> +{
> + struct ltc4306 *data = gpiochip_get_data(chip);
> +
> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
> + BIT(7 - offset), BIT(7 - offset));
> +}
> +
> +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);
> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
> + BIT(7 - offset), 0);
> +}
> +
> +static int ltc4306_gpio_set_config(struct gpio_chip *chip,
> + unsigned int offset, unsigned long config)
> +{
> + struct ltc4306 *data = gpiochip_get_data(chip);
> + unsigned int val;
> +
> + switch (pinconf_to_config_param(config)) {
> + case PIN_CONFIG_DRIVE_OPEN_DRAIN:
> + val = 0;
> + break;
> + case PIN_CONFIG_DRIVE_PUSH_PULL:
> + val = BIT(4 - offset);
> + break;
> + default:
> + return -ENOTSUPP;
> + }
> +
> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
> + BIT(4 - offset), val);
> +}
> +
> +static int ltc4306_gpio_init(struct ltc4306 *data)
> +{
> + struct device *dev = regmap_get_device(data->regmap);
> +
> + if (!data->chip->num_gpios)
> + return 0;
> +
> + data->gpiochip.label = dev_name(dev);
> + data->gpiochip.base = -1;
> + data->gpiochip.ngpio = data->chip->num_gpios;
> + data->gpiochip.parent = dev;
> + data->gpiochip.can_sleep = true;
> + data->gpiochip.direction_input = ltc4306_gpio_direction_input;
> + data->gpiochip.direction_output = ltc4306_gpio_direction_output;
I'm missing a get_direction op?
> + 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 */
> + regmap_write(data->regmap, LTC_REG_MODE, LTC_GPIO_ALL_INPUT);
> +
> + return devm_gpiochip_add_data(dev, &data->gpiochip, data);
> +}
> +
> +static int ltc4306_select_mux(struct i2c_mux_core *muxc, u32 chan)
> +{
> + struct ltc4306 *data = i2c_mux_priv(muxc);
> +
> + return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
> + LTC_SWITCH_MASK, BIT(7 - chan));
Since the bits outside the mask are ignored for writes, I'd go with
regmap_write. Especially since those bits are volatile, which admittedly
will not have much impact until there is a need to read those volatile
bits outside the mask. But still.
> +}
> +
> +static int ltc4306_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
> +{
> + struct ltc4306 *data = i2c_mux_priv(muxc);
> +
> + return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
> + LTC_SWITCH_MASK, 0);
Dito.
> +}
> +
> +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;
> + struct i2c_mux_core *muxc;
> + struct ltc4306 *data;
> + struct gpio_desc *gpio;
> + bool idle_disc = false;
> + int num, ret;
> +
> + if (of_node)
> + idle_disc = of_property_read_bool(of_node,
> + "i2c-mux-idle-disconnect");
> +
> + muxc = i2c_mux_alloc(adap, &client->dev,
> + LTC4306_MAX_NCHANS, sizeof(*data),
Hmmm, I didn't see this before, but if you do some more rearranging, it
should be possible to replace LTC4306_MAX_NCHANS with data->chip->nchans
and reduce resource waste for ltc4305. But it's just storage for two
pointers which is really really minor... Feel free to ignore.
But you want to set a good example, right :-)
> + I2C_MUX_LOCKED, ltc4306_select_mux,
> + idle_disc ? ltc4306_deselect_mux : NULL);
> + if (!muxc)
> + return -ENOMEM;
> + data = i2c_mux_priv(muxc);
> +
> + i2c_set_clientdata(client, muxc);
> +
> + data->regmap = devm_regmap_init_i2c(client, <c4306_regmap_config);
> + if (IS_ERR(data->regmap)) {
> + ret = PTR_ERR(data->regmap);
> + dev_err(&client->dev, "Failed to allocate register map: %d\n",
> + ret);
> + return ret;
> + }
> +
> + /* Reset and enable the mux if an enable GPIO is specified. */
> + gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_LOW);
> + if (IS_ERR(gpio))
> + return PTR_ERR(gpio);
> +
> + if (gpio) {
> + udelay(1);
> + gpiod_set_value(gpio, 1);
> + }
> +
> + /*
> + * Write the mux register at addr to verify
> + * that the mux is in fact present. This also
> + * initializes the mux to disconnected state.
> + */
> + if (regmap_write(data->regmap, LTC_REG_SWITCH, 0) < 0) {
> + dev_warn(&client->dev, "probe failed\n");
> + return -ENODEV;
> + }
> +
> + if (of_node) {
> + unsigned int val = 0;
> +
> + data->chip = of_device_get_match_data(&client->dev);
> +
> + if (of_property_read_bool(of_node,
> + "ltc,downstream-accelerators-enable"))
> + val |= LTC_DOWNSTREAM_ACCL_EN;
> +
> + if (of_property_read_bool(of_node,
> + "ltc,upstream-accelerators-enable"))
> + val |= LTC_UPSTREAM_ACCL_EN;
> +
> + if (regmap_write(data->regmap, LTC_REG_CONFIG, val) < 0)
> + return -ENODEV;
> + } else {
> + data->chip = &chips[id->driver_data];
> + }
> +
> + 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++) {
> + ret = i2c_mux_add_adapter(muxc, 0, num, 0);
> + if (ret) {
> + i2c_mux_del_adapters(muxc);
> + return ret;
> + }
> + }
> +
> + dev_info(&client->dev,
> + "registered %d multiplexed busses for I2C switch %s\n",
> + num, client->name);
> +
> + return 0;
> +}
> +
> +static int ltc4306_remove(struct i2c_client *client)
> +{
> + struct i2c_mux_core *muxc = i2c_get_clientdata(client);
> +
> + i2c_mux_del_adapters(muxc);
> +
> + return 0;
> +}
> +
> +static struct i2c_driver ltc4306_driver = {
> + .driver = {
> + .name = "ltc4306",
> + .of_match_table = of_match_ptr(ltc4306_of_match),
> + },
> + .probe = ltc4306_probe,
> + .remove = ltc4306_remove,
> + .id_table = ltc4306_id,
> +};
> +
> +module_i2c_driver(ltc4306_driver);
> +
> +MODULE_AUTHOR("Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>");
> +MODULE_DESCRIPTION("Linear Technology LTC4306, LTC4305 I2C mux/switch driver");
> +MODULE_LICENSE("GPL v2");
>
--
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/3] ARM: dts: rockchip: Add support for phyCORE-RK3288 SoM
From: Heiko Stübner @ 2017-04-06 8:47 UTC (permalink / raw)
To: Wadim Egorov
Cc: robh+dt, mark.rutland, linux, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <1872284.4EEa8KbvLF@phil>
Am Donnerstag, 6. April 2017, 10:30:46 CEST schrieb Heiko Stuebner:
> Am Montag, 3. April 2017, 12:23:03 CEST schrieb Wadim Egorov:
> > The phyCORE-RK3288 is a SoM (System on Module) containing a RK3288 SoC.
> > The module can be connected to different carrier boards.
> > It can be also equipped with different RAM, SPI flash and eMMC variants.
> >
> > The Rapid Development Kit option is using the following setup:
> > - 1 GB DDR3 RAM (2 Banks)
> > - 1x 4 KB EEPROM
> > - DP83867 Gigabit Ethernet PHY
> > - 16 MB SPI Flash
> > - 4 GB eMMC Flash
> >
> > Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
>
> applied for 4.12 with the following minor changes:
had to unapply again ... can you please check the license of the files
They're currently GPL2-only, while we use a combined GPL+X11 license
everywhere else. See every other Rockchip dts (and even most other
socs) for reference.
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH 3/4] pwm: tegra: Add DT binding details to configure pin in suspends/resume
From: Jon Hunter @ 2017-04-06 8:57 UTC (permalink / raw)
To: Laxman Dewangan, thierry.reding, robh+dt, mark.rutland
Cc: linux-pwm, devicetree, linux-tegra, linux-kernel
In-Reply-To: <1491401626-31303-4-git-send-email-ldewangan@nvidia.com>
On 05/04/17 15:13, Laxman Dewangan wrote:
> In some of NVIDIA Tegra's platform, PWM controller is used to
> control the PWM controlled regulators. PWM signal is connected to
> the VID pin of the regulator where duty cycle of PWM signal decide
> the voltage level of the regulator output.
>
> The tristate (high impedance of PWM pin form Tegra) also define
> one of the state of PWM regulator which needs to be configure in
> suspend state of system.
>
> Add DT binding details to provide the pin configuration state
> from PWM and pinctrl DT node in suspend and active state of
> the system.
>
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
> ---
> .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
> index b4e7377..145c323 100644
> --- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
> +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
> @@ -19,6 +19,19 @@ Required properties:
> - reset-names: Must include the following entries:
> - pwm
>
> +Optional properties:
> +============================
> +In some of the interface like PWM based regualator device, it is required
> +to configure the pins diffrently in different states, specially in suspend
s/diffrently/differently
s/specially/especially
> +state of the system. The configuration of pin is provided via the pinctrl
> +DT node as detailed in the pinctrl DT binding document
> + Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> +
> +The PWM node will have following optional properties.
> +pinctrl-names: Pin state names. Must be "suspend" and "resume".
Why not just use the pre-defined names here? There is a pre-defined name
for "default", "idle" and "sleep" and then you can use the following
APIs and avoid the lookup of the state ...
pinctrl_pm_select_default_state()
pinctrl_pm_select_idle_state()
pinctrl_pm_select_sleep_state()
Note for i2c [0][1], I used "default" as the active/on state (which I
know is not that descriptive) and then used 'idle' as the suspended
state. This way we don't need any custom names.
Cheers
Jon
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/i2c/busses/i2c-tegra.c?id=718917b9875fcfa6450e7274d2727c4680c3591a
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/nvidia/tegra210.dtsi?id=66b2d6e9c93bc5bed55afda80c84bf0325c14ad4
--
nvpublic
^ permalink raw reply
* [PATCH v3 0/3] clk: Add support for IDT 5P49V5935
From: Alexey Firago @ 2017-04-06 9:15 UTC (permalink / raw)
To: mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, geert-Td1EMuHUCqxL1ZNQvxDV9g,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Alexey Firago
This series adds support for IDT VersaClock 5P49V5935 programmable clock
generator to the existing clk-versaclock5 driver.
Patches were verified on Avnet UltraZed-EG board with IO Carrier Card.
Changes in V2:
- Introduce vc5_chip_info structure describing chip features
- Set vc5_chip_info for the supported chips using clk_vc5_of_match[].data
- Add 5P49V5935 support using vc5_chip_info approach
- Fix idx comparison in vc5_of_clk_get ('>' to '>=')
Changes in V3:
- Change type of clk_fod_cnt and clk_out_cnt to unsigned int
- Add missed 'const' to vc5_chip_info instance declaration
- Use of_device_get_match_data() to initialize vc5_chip_info on probe
Alexey Firago (3):
clk: vc5: Add structure to describe particular chip features
clk: vc5: Add bindings for IDT VersaClock 5P49V5935
clk: vc5: Add support for IDT VersaClock 5P49V5935
.../devicetree/bindings/clock/idt,versaclock5.txt | 16 ++++-
drivers/clk/clk-versaclock5.c | 76 +++++++++++++++++-----
2 files changed, 71 insertions(+), 21 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 1/3] clk: vc5: Add structure to describe particular chip features
From: Alexey Firago @ 2017-04-06 9:15 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, marek.vasut, geert, linux-clk,
devicetree
Cc: Alexey Firago
In-Reply-To: <1491470130-6655-1-git-send-email-alexey_firago@mentor.com>
Introduce vc5_chip_info structure to describe features of a particular
VC5 chip (id, number of FODs, number of outputs, flags).
For now flags are only used to indicate if chip has internal XTAL.
vc5_chip_info is set on probe from the matched of_device_id->data.
Also add defines to specify maximum number of FODs and clock outputs
supported by the driver.
With these changes it should be easier to extend driver to support
more VC5 models.
Signed-off-by: Alexey Firago <alexey_firago@mentor.com>
---
drivers/clk/clk-versaclock5.c | 65 +++++++++++++++++++++++++++++++------------
1 file changed, 47 insertions(+), 18 deletions(-)
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 56741f3..4e81fb1 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -113,12 +113,30 @@
#define VC5_MUX_IN_XIN BIT(0)
#define VC5_MUX_IN_CLKIN BIT(1)
+/* Maximum number of clk_out supported by this driver */
+#define VC5_MAX_CLK_OUT_NUM 3
+
+/* Maximum number of FODs supported by this driver */
+#define VC5_MAX_FOD_NUM 2
+
+/* flags to describe chip features */
+/* chip has built-in oscilator */
+#define VC5_HAS_INTERNAL_XTAL BIT(0)
+
/* Supported IDT VC5 models. */
enum vc5_model {
IDT_VC5_5P49V5923,
IDT_VC5_5P49V5933,
};
+/* Structure to describe features of a particular VC5 model */
+struct vc5_chip_info {
+ const enum vc5_model model;
+ const unsigned int clk_fod_cnt;
+ const unsigned int clk_out_cnt;
+ u32 flags;
+};
+
struct vc5_driver_data;
struct vc5_hw_data {
@@ -132,15 +150,15 @@ struct vc5_hw_data {
struct vc5_driver_data {
struct i2c_client *client;
struct regmap *regmap;
- enum vc5_model model;
+ const struct vc5_chip_info *chip_info;
struct clk *pin_xin;
struct clk *pin_clkin;
unsigned char clk_mux_ins;
struct clk_hw clk_mux;
struct vc5_hw_data clk_pll;
- struct vc5_hw_data clk_fod[2];
- struct vc5_hw_data clk_out[3];
+ struct vc5_hw_data clk_fod[VC5_MAX_FOD_NUM];
+ struct vc5_hw_data clk_out[VC5_MAX_CLK_OUT_NUM];
};
static const char * const vc5_mux_names[] = {
@@ -563,7 +581,7 @@ static struct clk_hw *vc5_of_clk_get(struct of_phandle_args *clkspec,
struct vc5_driver_data *vc5 = data;
unsigned int idx = clkspec->args[0];
- if (idx > 2)
+ if (idx >= vc5->chip_info->clk_out_cnt)
return ERR_PTR(-EINVAL);
return &vc5->clk_out[idx].hw;
@@ -586,12 +604,10 @@ static const struct of_device_id clk_vc5_of_match[];
static int vc5_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- const struct of_device_id *of_id =
- of_match_device(clk_vc5_of_match, &client->dev);
struct vc5_driver_data *vc5;
struct clk_init_data init;
const char *parent_names[2];
- unsigned int n, idx;
+ unsigned int n, idx = 0;
int ret;
vc5 = devm_kzalloc(&client->dev, sizeof(*vc5), GFP_KERNEL);
@@ -600,7 +616,7 @@ static int vc5_probe(struct i2c_client *client,
i2c_set_clientdata(client, vc5);
vc5->client = client;
- vc5->model = (enum vc5_model)of_id->data;
+ vc5->chip_info = of_device_get_match_data(&client->dev);
vc5->pin_xin = devm_clk_get(&client->dev, "xin");
if (PTR_ERR(vc5->pin_xin) == -EPROBE_DEFER)
@@ -622,8 +638,7 @@ static int vc5_probe(struct i2c_client *client,
if (!IS_ERR(vc5->pin_xin)) {
vc5->clk_mux_ins |= VC5_MUX_IN_XIN;
parent_names[init.num_parents++] = __clk_get_name(vc5->pin_xin);
- } else if (vc5->model == IDT_VC5_5P49V5933) {
- /* IDT VC5 5P49V5933 has built-in oscilator. */
+ } else if (vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL) {
vc5->pin_xin = clk_register_fixed_rate(&client->dev,
"internal-xtal", NULL,
0, 25000000);
@@ -672,8 +687,8 @@ static int vc5_probe(struct i2c_client *client,
}
/* Register FODs */
- for (n = 0; n < 2; n++) {
- idx = vc5_map_index_to_output(vc5->model, n);
+ for (n = 0; n < vc5->chip_info->clk_fod_cnt; n++) {
+ idx = vc5_map_index_to_output(vc5->chip_info->model, n);
memset(&init, 0, sizeof(init));
init.name = vc5_fod_names[idx];
init.ops = &vc5_fod_ops;
@@ -709,8 +724,8 @@ static int vc5_probe(struct i2c_client *client,
}
/* Register FOD-connected OUTx outputs */
- for (n = 1; n < 3; n++) {
- idx = vc5_map_index_to_output(vc5->model, n - 1);
+ for (n = 1; n < vc5->chip_info->clk_out_cnt; n++) {
+ idx = vc5_map_index_to_output(vc5->chip_info->model, n - 1);
parent_names[0] = vc5_fod_names[idx];
if (n == 1)
parent_names[1] = vc5_mux_names[0];
@@ -744,7 +759,7 @@ static int vc5_probe(struct i2c_client *client,
return 0;
err_clk:
- if (vc5->model == IDT_VC5_5P49V5933)
+ if (vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)
clk_unregister_fixed_rate(vc5->pin_xin);
return ret;
}
@@ -755,12 +770,26 @@ static int vc5_remove(struct i2c_client *client)
of_clk_del_provider(client->dev.of_node);
- if (vc5->model == IDT_VC5_5P49V5933)
+ if (vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)
clk_unregister_fixed_rate(vc5->pin_xin);
return 0;
}
+static const struct vc5_chip_info idt_5p49v5923_info = {
+ .model = IDT_VC5_5P49V5923,
+ .clk_fod_cnt = 2,
+ .clk_out_cnt = 3,
+ .flags = 0,
+};
+
+static const struct vc5_chip_info idt_5p49v5933_info = {
+ .model = IDT_VC5_5P49V5933,
+ .clk_fod_cnt = 2,
+ .clk_out_cnt = 3,
+ .flags = VC5_HAS_INTERNAL_XTAL,
+};
+
static const struct i2c_device_id vc5_id[] = {
{ "5p49v5923", .driver_data = IDT_VC5_5P49V5923 },
{ "5p49v5933", .driver_data = IDT_VC5_5P49V5933 },
@@ -769,8 +798,8 @@ static const struct i2c_device_id vc5_id[] = {
MODULE_DEVICE_TABLE(i2c, vc5_id);
static const struct of_device_id clk_vc5_of_match[] = {
- { .compatible = "idt,5p49v5923", .data = (void *)IDT_VC5_5P49V5923 },
- { .compatible = "idt,5p49v5933", .data = (void *)IDT_VC5_5P49V5933 },
+ { .compatible = "idt,5p49v5923", .data = &idt_5p49v5923_info },
+ { .compatible = "idt,5p49v5933", .data = &idt_5p49v5933_info },
{ },
};
MODULE_DEVICE_TABLE(of, clk_vc5_of_match);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] clk: vc5: Add bindings for IDT VersaClock 5P49V5935
From: Alexey Firago @ 2017-04-06 9:15 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, marek.vasut, geert, linux-clk,
devicetree
Cc: Alexey Firago
In-Reply-To: <1491470130-6655-1-git-send-email-alexey_firago@mentor.com>
IDT VersaClock 5 5P49V5935 has 4 clock outputs, 4 fractional dividers.
Input clock source can be taken from either integrated crystal or from
external reference clock.
Signed-off-by: Alexey Firago <alexey_firago@mentor.com>
---
.../devicetree/bindings/clock/idt,versaclock5.txt | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
index 87e9c47..53d7e50 100644
--- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
+++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
@@ -6,18 +6,21 @@ from 3 to 12 output clocks.
==I2C device node==
Required properties:
-- compatible: shall be one of "idt,5p49v5923" , "idt,5p49v5933".
+- compatible: shall be one of "idt,5p49v5923" , "idt,5p49v5933" ,
+ "idt,5p49v5935".
- reg: i2c device address, shall be 0x68 or 0x6a.
- #clock-cells: from common clock binding; shall be set to 1.
- clocks: from common clock binding; list of parent clock handles,
- 5p49v5923: (required) either or both of XTAL or CLKIN
reference clock.
- - 5p49v5933: (optional) property not present (internal
+ - 5p49v5933 and
+ - 5p49v5935: (optional) property not present (internal
Xtal used) or CLKIN reference
clock.
- clock-names: from common clock binding; clock input names, can be
- 5p49v5923: (required) either or both of "xin", "clkin".
- - 5p49v5933: (optional) property not present or "clkin".
+ - 5p49v5933 and
+ - 5p49v5935: (optional) property not present or "clkin".
==Mapping between clock specifier and physical pins==
@@ -34,6 +37,13 @@ clock specifier, the following mapping applies:
1 -- OUT1
2 -- OUT4
+5P49V5935:
+ 0 -- OUT0_SEL_I2CB
+ 1 -- OUT1
+ 2 -- OUT2
+ 3 -- OUT3
+ 4 -- OUT4
+
==Example==
/* 25MHz reference crystal */
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/3] clk: vc5: Add support for IDT VersaClock 5P49V5935
From: Alexey Firago @ 2017-04-06 9:15 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, marek.vasut, geert, linux-clk,
devicetree
Cc: Alexey Firago
In-Reply-To: <1491470130-6655-1-git-send-email-alexey_firago@mentor.com>
Update IDT VersaClock 5 driver to support 5P49V5935. This chip has
two clock inputs (internal XTAL or external CLKIN), four fractional
dividers (FODs) and five clock outputs (four universal clock outputs
and one reference clock output at OUT0_SELB_I2C).
Current driver supports up to 2 FODs and up to 3 clock outputs. This
patch sets max number of supported FODs to 4 and max number of supported
clock outputs to 5.
Signed-off-by: Alexey Firago <alexey_firago@mentor.com>
---
drivers/clk/clk-versaclock5.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 4e81fb1..34c4e5a 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -114,10 +114,10 @@
#define VC5_MUX_IN_CLKIN BIT(1)
/* Maximum number of clk_out supported by this driver */
-#define VC5_MAX_CLK_OUT_NUM 3
+#define VC5_MAX_CLK_OUT_NUM 5
/* Maximum number of FODs supported by this driver */
-#define VC5_MAX_FOD_NUM 2
+#define VC5_MAX_FOD_NUM 4
/* flags to describe chip features */
/* chip has built-in oscilator */
@@ -127,6 +127,7 @@
enum vc5_model {
IDT_VC5_5P49V5923,
IDT_VC5_5P49V5933,
+ IDT_VC5_5P49V5935,
};
/* Structure to describe features of a particular VC5 model */
@@ -594,6 +595,7 @@ static int vc5_map_index_to_output(const enum vc5_model model,
case IDT_VC5_5P49V5933:
return (n == 0) ? 0 : 3;
case IDT_VC5_5P49V5923:
+ case IDT_VC5_5P49V5935:
default:
return n;
}
@@ -790,9 +792,17 @@ static const struct vc5_chip_info idt_5p49v5933_info = {
.flags = VC5_HAS_INTERNAL_XTAL,
};
+static const struct vc5_chip_info idt_5p49v5935_info = {
+ .model = IDT_VC5_5P49V5935,
+ .clk_fod_cnt = 4,
+ .clk_out_cnt = 5,
+ .flags = VC5_HAS_INTERNAL_XTAL,
+};
+
static const struct i2c_device_id vc5_id[] = {
{ "5p49v5923", .driver_data = IDT_VC5_5P49V5923 },
{ "5p49v5933", .driver_data = IDT_VC5_5P49V5933 },
+ { "5p49v5935", .driver_data = IDT_VC5_5P49V5935 },
{ }
};
MODULE_DEVICE_TABLE(i2c, vc5_id);
@@ -800,6 +810,7 @@ MODULE_DEVICE_TABLE(i2c, vc5_id);
static const struct of_device_id clk_vc5_of_match[] = {
{ .compatible = "idt,5p49v5923", .data = &idt_5p49v5923_info },
{ .compatible = "idt,5p49v5933", .data = &idt_5p49v5933_info },
+ { .compatible = "idt,5p49v5935", .data = &idt_5p49v5935_info },
{ },
};
MODULE_DEVICE_TABLE(of, clk_vc5_of_match);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH V10 03/12] of: dma: Move range size workaround to of_dma_get_range()
From: Sricharan R @ 2017-04-06 9:35 UTC (permalink / raw)
To: Frank Rowand, robin.murphy-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
joro-zLv9SwRftAIdnm+yROfE0A, lorenzo.pieralisi-5wv7dgnIgG8,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, tn-nYOzD4b6Jr9Wk0Htik3J/w,
hanjun.guo-QSEj5FYQhm4dnm+yROfE0A, okaya-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, sudeep.holla-5wv7dgnIgG8,
rjw-LthD3rsA81gm4RdzfppkhA, lenb-DgEjT+Ai2ygdnm+yROfE0A,
catalin.marinas-5wv7dgnIgG8, arnd-r2nGTMty4D4,
linux-arch-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
In-Reply-To: <58E5DF13.2020700-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Frank,
On 4/6/2017 11:54 AM, Frank Rowand wrote:
> On 04/04/17 03:18, Sricharan R wrote:
>> From: Laurent Pinchart <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>>
>> Invalid dma-ranges values should be worked around when retrieving the
>> DMA range in of_dma_get_range(), not by all callers of the function.
>> This isn't much of a problem now that we have a single caller, but that
>> situation will change when moving DMA configuration to device probe
>> time.
>
> Please drop this patch from the series. I just now sent Rob an
> alternative that reflects other changes that have occurred since
> this patch series was first created many, many moons ago
> (https://lkml.org/lkml/2017/4/6/53).
ok, would drop this.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH] clk: stm32h7: Add stm32h743 clock driver
From: Gabriel Fernandez @ 2017-04-06 9:35 UTC (permalink / raw)
To: Stephen Boyd
Cc: Mark Rutland, devicetree, daniel.thompson, radoslaw.pietrzyk,
Alexandre Torgue, Arnd Bergmann, Nicolas Pitre, andrea.merello,
Michael Turquette, olivier.bideau, Russell King, linux-kernel,
Rob Herring, ludovic.barre, Maxime Coquelin, amelie.delaunay,
Lee Jones, linux-clk, linux-arm-kernel
In-Reply-To: <20170405223233.GJ7065@codeaurora.org>
Hi Stephen,
On 04/06/2017 12:32 AM, Stephen Boyd wrote:
> On 03/15, gabriel.fernandez@st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> This patch enables clocks for STM32H743 boards.
> Like what clocks exactly? All of them?
>
Yes all of them, it's new IP
>> diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
>> new file mode 100644
>> index 0000000..9d4b587
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
>> @@ -0,0 +1,152 @@
>> +STMicroelectronics STM32H7 Reset and Clock Controller
>> +=====================================================
>> +
>> +The RCC IP is both a reset and a clock controller.
>> +
>> +Please refer to clock-bindings.txt for common clock controller binding usage.
>> +Please also refer to reset.txt for common reset controller binding usage.
>> +
>> +Required properties:
>> +- compatible: Should be:
>> + "st,stm32h743-rcc"
>> +
>> +- reg: should be register base and length as documented in the
>> + datasheet
>> +
>> +- #reset-cells: 1, see below
>> +
>> +- #clock-cells : from common clock binding; shall be set to 1
>> +
>> +- clocks: External oscillator clock phandle
>> + - high speed external clock signal (HSE)
>> + - low speed external clock signal (LSE)
>> + - external I2S clock (I2S_CKIN)
>> +
>> +- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
>> + write protection (RTC clock).
>> +
>> +- pll x node: Allow to register a pll with specific parameters.
>> + Please see PLL section below.
>> +
>> +Example:
>> +
>> + rcc: rcc@58024400 {
>> + #reset-cells = <1>;
>> + #clock-cells = <2>
>> + compatible = "st,stm32h743-rcc", "st,stm32-rcc";
>> + reg = <0x58024400 0x400>;
>> + clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>;
>> +
>> + st,syscfg = <&pwrcfg>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + vco1@58024430 {
>> + #clock-cells = <0>;
>> + compatible = "stm32,pll";
>> + reg = <0>;
> reg is super confusing and doesn't match unit address.
ok i fixed it in the v2
>
>> + };
> Why? Shouldn't we know this from the compatible string how many
> PLLs there are and where they're located? Export the PLLs through
> rcc node's clock-cells?
>
Because i need to offer the possibility to change the PLL VCO
frequencies at the start-up of this driver clock.
The VCO algorithm needs a division factor, a multiplication factor and a
fractional factor.
Lot's of solution are possible for one frequency and it's nightmare to
satisfy the 3 output dividers of the PLL.
>> +
>> + vco2@58024438 {
>> + #clock-cells = <0>;
>> + compatible = "stm32,pll";
>> + reg = <1>;
> reg is super confusing and doesn't match unit address.
>
>> + st,clock-div = <2>;
>> + st,clock-mult = <40>;
>> + st,frac-status = <0>;
>> + st,frac = <0>;
>> + st,vcosel = <1>;
>> + st,pllrge = <2>;
> Does this stuff change on a per-board basis? I hope none of these
> properties need to be in DT.
These properties are optionals.
I absolute need it to custumize VCO frequencies of a pll without the
boot loader..
i suppressed "st,frac-status" and "st,pllrge" in the v2
>
>> + };
>> + };
>> +
>> +
>> +STM32H7 PLL
>> +-----------
>> +
> [...]
>> +
>> +Specifying softreset control of devices
>> +=======================================
>> +
>> +Device nodes should specify the reset channel required in their "resets"
>> +property, containing a phandle to the reset device node and an index specifying
>> +which channel to use.
>> +The index is the bit number within the RCC registers bank, starting from RCC
>> +base address.
>> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
>> +Where bit_offset is the bit offset within the register.
>> +
>> +For example, for CRC reset:
>> + crc = AHB4RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x88 / 4 * 32 + 19 = 1107
>> +
>> +All available preprocessor macros for reset are defined dt-bindings//mfd/stm32h7-rcc.h
> One too many slashes?
ok i will fix it
>
>> +header and can be used in device tree sources.
>> +
>> +example:
>> +
>> + timer2 {
>> + resets = <&rcc STM32H7_APB1L_RESET(TIM2)>;
>> + };
>> diff --git a/drivers/clk/clk-stm32h7.c b/drivers/clk/clk-stm32h7.c
>> new file mode 100644
>> index 0000000..c8eb729
>> --- /dev/null
>> +++ b/drivers/clk/clk-stm32h7.c
>> @@ -0,0 +1,1586 @@
>> +/*
>> + * Copyright (C) Gabriel Fernandez 2017
>> + * Author: Gabriel Fernandez <gabriel.fernandez@st.com>
>> + *
>> + * License terms: GPL V2.0.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/clk.h>
> Is this used?
No i will suppress it
>
>> +#include <linux/clk-provider.h>
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/slab.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/regmap.h>
>> +
>> +#include <dt-bindings/clock/stm32h7-clks.h>
>> +
>> +/* Reset Clock Control Registers */
>> +#define RCC_CR 0x00
>> +#define RCC_CFGR 0x10
>> +#define RCC_D1CFGR 0x18
>> +#define RCC_D2CFGR 0x1C
>> +#define RCC_D3CFGR 0x20
>> +#define RCC_PLLCKSELR 0x28
>> +#define RCC_PLLCFGR 0x2C
>> +#define RCC_PLL1DIVR 0x30
>> +#define RCC_PLL1FRACR 0x34
>> +#define RCC_PLL2DIVR 0x38
>> +#define RCC_PLL2FRACR 0x3C
>> +#define RCC_PLL3DIVR 0x40
>> +#define RCC_PLL3FRACR 0x44
>> +#define RCC_D1CCIPR 0x4C
>> +#define RCC_D2CCIP1R 0x50
>> +#define RCC_D2CCIP2R 0x54
>> +#define RCC_D3CCIPR 0x58
>> +#define RCC_BDCR 0x70
>> +#define RCC_CSR 0x74
>> +#define RCC_AHB3ENR 0xD4
>> +#define RCC_AHB1ENR 0xD8
>> +#define RCC_AHB2ENR 0xDC
>> +#define RCC_AHB4ENR 0xE0
>> +#define RCC_APB3ENR 0xE4
>> +#define RCC_APB1LENR 0xE8
>> +#define RCC_APB1HENR 0xEC
>> +#define RCC_APB2ENR 0xF0
>> +#define RCC_APB4ENR 0xF4
>> +
>> +static DEFINE_SPINLOCK(rlock);
> This is super generic and will make lockdep debugging sad.
> Perhaps stm32rcc_lock?
ok
>
>> +
>> +static void __iomem *base;
>> +static struct regmap *pdrm;
>> +static struct clk_hw **hws;
>> +
>> +/* System clock parent */
>> +static const char * const sys_src[] = {
>> + "hsi_ck", "csi_ck", "hse_ck", "pll1_p" };
>> +
>> +static const char * const tracein_src[] = {
>> + "hsi_ck", "csi_ck", "hse_ck", "pll1_r" };
> [...]
>> +
>> +static unsigned long pll_fd_recalc_rate(struct clk_hw *hw,
>> + unsigned long parent_rate)
>> +{
>> + struct stm32_pll_obj *clk_elem = to_pll(hw);
>> + struct stm32_fractional_divider *fd = &clk_elem->div;
>> + unsigned long m, n;
>> + u32 val, mask;
>> + u64 rate, rate1 = 0;
>> +
>> + val = clk_readl(fd->mreg);
> Please don't use clk_readl() unless you need it for some reason.
ok
>
>> + mask = (GENMASK(fd->mwidth - 1, 0) << fd->mshift);
>> + m = (val & mask) >> fd->mshift;
>> +
>> + val = clk_readl(fd->nreg);
>> + mask = (GENMASK(fd->nwidth - 1, 0) << fd->nshift);
> Useless parentheses. And isn't GENMASK supposed to take the
> actual bit positions? Then we avoid overflow issues?
ok il will fix it.
>> + n = ((val & mask) >> fd->nshift) + 1;
>> +
>> + if (!n || !m)
>> + return parent_rate;
>> +
>> + rate = (u64)parent_rate * n;
>> + do_div(rate, m);
>> +
>> + if (pll_frac_is_enabled(hw)) {
>> + val = pll_read_frac(hw);
>> + rate1 = (u64) parent_rate * (u64) val;
>> + do_div(rate1, (m * 8191));
>> + }
>> +
>> + return rate + rate1;
>> +}
>> +
> [...]
>> +
>> + /* Micro-controller clocks */
>> + for (n = 0; n < ARRAY_SIZE(mco_clk); n++) {
>> + get_cfg_composite_div(&mco_clk_cfg, &mco_clk[n], &c_cfg,
>> + &rlock);
>> +
>> + hws[MCO_BANK + n] = clk_hw_register_composite(NULL,
>> + mco_clk[n].name,
>> + mco_clk[n].parent_name,
>> + mco_clk[n].num_parents,
>> + c_cfg.mux_hw, c_cfg.mux_ops,
>> + c_cfg.div_hw, c_cfg.div_ops,
>> + c_cfg.gate_hw, c_cfg.gate_ops,
>> + mco_clk[n].flags);
>> + }
>> +
>> + of_clk_add_hw_provider(np, of_clk_hw_onecell_get, clk_data);
>> +
>> + return;
>> +
>> +err_free_clks:
>> + kfree(clk_data);
>> +}
>> +CLK_OF_DECLARE_DRIVER(stm32h7_rcc, "st,stm32h743-rcc", stm32h7_rcc_init);
> Is there another driver that uses the same register space?
> Nothing showing up in -next right now. Perhaps a comment should
> be added to indicate the other driver.
Yes the reset controler.
ok il will add a comment.
BR
Gabriel
^ permalink raw reply
* Re: [PATCH v6 19/39] media: Add i.MX media core driver
From: Philipp Zabel @ 2017-04-06 9:43 UTC (permalink / raw)
To: Steve Longerbeam
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
fabio.estevam-3arQi8VN3Tc, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
nick-gcszYUEDH4VrovVCs/uTlw, markus.heiser-O6JHGLzbNUwb1SvskN2V4Q,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
bparrot-l0cyMroinI0, geert-Td1EMuHUCqxL1ZNQvxDV9g,
arnd-r2nGTMty4D4, sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw,
robert.jarzmik-GANU6spQydw, songjun.wu-UWL1GkI3JZL3oGB3hsPCZA,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
shuah-DgEjT+Ai2ygdnm+yROfE0A, sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
pavel-+ZI9xUNit7I, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490661656-10318-20-git-send-email-steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On Mon, 2017-03-27 at 17:40 -0700, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
[...]
> diff --git a/drivers/staging/media/imx/imx-media-of.c b/drivers/staging/media/imx/imx-media-of.c
> new file mode 100644
> index 0000000..b383be4
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-of.c
> @@ -0,0 +1,267 @@
[...]
> +/*
> + * find the remote device node and remote port id (remote pad #)
> + * given local endpoint node
> + */
> +static void of_get_remote_pad(struct device_node *epnode,
> + struct device_node **remote_node,
> + int *remote_pad)
> +{
> + struct device_node *rp, *rpp;
> + struct device_node *remote;
> +
> + rp = of_graph_get_remote_port(epnode);
> + rpp = of_graph_get_remote_port_parent(epnode);
> +
> + if (of_device_is_compatible(rpp, "fsl,imx6q-ipu")) {
> + /* the remote is one of the CSI ports */
> + remote = rp;
> + *remote_pad = 0;
> + of_node_put(rpp);
> + } else {
> + remote = rpp;
> + of_property_read_u32(rp, "reg", remote_pad);
If this fails because there is no reg property, *remote_pad will keep
the previous value. It should be set to 0 in this case.
----------8<----------
--- a/drivers/staging/media/imx/imx-media-of.c
+++ b/drivers/staging/media/imx/imx-media-of.c
@@ -85,7 +85,9 @@ static void of_get_remote_pad(struct device_node *epnode,
of_node_put(rpp);
} else {
remote = rpp;
- of_property_read_u32(rp, "reg", remote_pad);
+ /* FIXME port number and pad index are not the same */
+ if (of_property_read_u32(rp, "reg", remote_pad))
+ *remote_pad = 0;
of_node_put(rp);
}
---------->8----------
regards
Philipp
--
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 0/4] arm64: renesas: enable M3ULCB board peripherals
From: Geert Uytterhoeven @ 2017-04-06 9:53 UTC (permalink / raw)
To: Simon Horman
Cc: Vladimir Barinov, Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
Sjoerd Simons
In-Reply-To: <1489788135.8957.2.camel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
Hi Simon,
On Fri, Mar 17, 2017 at 11:02 PM, Sjoerd Simons
<sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> wrote:
> On Thu, 2017-01-26 at 17:53 +0300, Vladimir Barinov wrote:
>> This adds the folowing:
>> - R8A7796 SoC based M3ULCB board peripherals
>>
>> Vladimir Barinov (4):
>> [1/4] arm64: dts: m3ulcb: enable I2C
>> [2/4] arm64: dts: m3ulcb: Update memory node to 2 GiB map
>> [3/4] arm64: dts: m3ulcb: enable EthernetAVB
>> [4/4] arm64: dts: m3ulcb: enable HS200 for eMMC
>
> Seems these didn't hit -next just yet, for this series (tested on a
> M3ULCB)
>
> Tested-By: Sjoerd Simons <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
It seems this series is still pending? Any reason (not) to apply it?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1
From: Philipp Zabel @ 2017-04-06 9:57 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Russell King - ARM Linux, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
Steve Longerbeam, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, nick-gcszYUEDH4VrovVCs/uTlw,
markus.heiser-O6JHGLzbNUwb1SvskN2V4Q,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
bparrot-l0cyMroinI0, geert-Td1EMuHUCqxL1ZNQvxDV9g,
arnd-r2nGTMty4D4, sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw,
robert.jarzmik-GANU6spQydw, songjun.wu-UWL1GkI3JZL3oGB3hsPCZA,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
shuah-DgEjT+Ai2ygdnm+yROfE0A, sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
pavel-+ZI9xUNit7I, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170405115336.7135e542-ch4gOOMV7nf/PtFMR13I2A@public.gmane.org>
On Wed, 2017-04-05 at 11:53 -0300, Mauro Carvalho Chehab wrote:
[...]
> There are a number of drivers that can work with different
> types of TV demodulators. Typical examples of such hardware can be
> found at em28xx, saa7134, cx88 drivers (among lots of other drivers).
> Those drivers don't use the subdev API. Instead, they use a generic
> helper function with sets the pipelines, based on the pad number.
>
> The problem here is that, currently, both MC API and MC core
> lacks a way to identify PAD ports per type, as the only information
> that a bridge driver has is a pad number. So, in order for a
> generic helper function to work, we had to hardcode pad numbers,
> in a way that it would work for all possible types of demods.
>
> It shouldn't be hard to add a "pad_type" information at media_pad
> struct, but passing such info to userspace requires a new API
> (we're calling it as "properties API"). Sakari was meant to send
> us an updated RFC for it[1] with a patchset, back in 2015, but
> this never happened.
>
> [1] https://linuxtv.org/news.php?entry=2015-08-17.mchehab
[...]
That would be most useful.
> So, in short, the tvp5150 demod doesn't decode audio, but there
> are other demods that do it.
>
> In the case of VBI, tvp5150 has actually two ways of reporting
> it:
>
> 1) via YOUT[7:0] pins. VBI information is transmitted as a
> set of raw samples, via an ancillary data block, during
> vertical/horizontal blanking intervals. So, yes, it shares
> the same hardware output, although the VBI contents are
> actually multiplexed there. Please notice that not all
> video out PADS encapsulate raw VBI the same way as tvp5150
> (and some devices even don't support raw VBI, like saa7110 and
> some models supported by saa7115 driver).
This is the physical interface that corresponds to the output port
(should be port@1) in the device tree. It should correspond to the video
output media entity pad.
What is unclear to is me whether the VBI media entity pad also should
correspond to the same physical interface / DT port.
> 2) via an interrupt that indicates that it decoded VBI data. The
> VBI information itself is there on FIFO, accessible via a set of
> registers (see "VBI Data processor" chapter at the datasheet).
>
> Currently, the driver doesn't support (2), because, at the time
> I wrote the driver, I didn't find a way to read the interrupts generated
> by tvp5150 at em28xx[1], due to the lack of em28xx documentation,
> but adding support for it shoudn't be hard. I may eventually do it
> when I have some time to play with my ISEE hardware.
>
> So, in the case of tvp5150 hardware, have those PADS:
>
> - Input baseband;
> - Video + raw VBI output;
> - sliced VBI output.
This DEMOD_PAD_VBI_OUT, does it correspond to 1) or 2) above?
> Yet, we need an always unconnected audio output, in order to support
> different demods out there.
Are you saying we have to keep pad[DEMOD_PAD_AUDIO_OUT] in tvp5150 even
though it doesn't exist because the framework can't cope with an
audio-less ATV_DECODER that only has three pads?
> [1] tvp5150 was written to support some em28xx-based devices
>
> >
> > > So, it has one input and three outputs. How does marking the direction
> > > in the port node (which would indicate that there was a data flow out of
> > > TVP5150 into the iMX6 capture) help identify which of those pads should
> > > be used?
> > >
> > > It would eliminate the input pad, but you still have three output pads
> > > to choose from.
> > >
> > > So no, your idea can't work.
> >
> > In this case, removal of the VBI and audio pads might make this work,
> > but in general this is true. In my opinion, to make this truly generic,
> > we need an interface to ask the driver which media entity pad a given
> > device tree port corresponds to, as there might not even be a single
> > media entity corresponding to all ports for more complex devices.
>
> Yes. We also need something like that at the userspace API.
thanks
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 2/4] dt-bindings: arm: Add bindings for SP9860G
From: Chunyan Zhang @ 2017-04-06 10:00 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Mark Rutland,
Catalin Marinas, Will Deacon, Arnd Bergmann, Mathieu Poirier,
Orson Zhai (翟京),
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Chunyan Zhang
In-Reply-To: <1490594802-27073-3-git-send-email-chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
Hello Greg,
I guess there will be no further comments on this patchset :), could
you please take the patches 2/3/4 through tty git?
Thanks,
Chunyan
On 27 March 2017 at 14:06, Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org> wrote:
> Added bindings for Spreadtrum SP9860G board and SC9860 SoC.
> This patch also revised bindings of SC9836 to make the format
> more clear.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/sprd.txt | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/sprd.txt b/Documentation/devicetree/bindings/arm/sprd.txt
> index 31a629d..3df034b 100644
> --- a/Documentation/devicetree/bindings/arm/sprd.txt
> +++ b/Documentation/devicetree/bindings/arm/sprd.txt
> @@ -1,11 +1,14 @@
> Spreadtrum SoC Platforms Device Tree Bindings
> ----------------------------------------------------
>
> -Sharkl64 is a Spreadtrum's SoC Platform which is based
> -on ARM 64-bit processor.
> +SC9836 openphone Board
> +Required root node properties:
> + - compatible = "sprd,sc9836-openphone", "sprd,sc9836";
>
> -SC9836 openphone board with SC9836 SoC based on the
> -Sharkl64 Platform shall have the following properties.
> +SC9860 SoC
> +Required root node properties:
> + - compatible = "sprd,sc9860"
>
> +SP9860G 3GFHD Board
> Required root node properties:
> - - compatible = "sprd,sc9836-openphone", "sprd,sc9836";
> + - compatible = "sprd,sp9860g-1h10", "sprd,sc9860";
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V10 03/12] of: dma: Move range size workaround to of_dma_get_range()
From: Robin Murphy @ 2017-04-06 10:03 UTC (permalink / raw)
To: Frank Rowand, Sricharan R, will.deacon-5wv7dgnIgG8,
joro-zLv9SwRftAIdnm+yROfE0A, lorenzo.pieralisi-5wv7dgnIgG8,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, tn-nYOzD4b6Jr9Wk0Htik3J/w,
hanjun.guo-QSEj5FYQhm4dnm+yROfE0A, okaya-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, sudeep.holla-5wv7dgnIgG8,
rjw-LthD3rsA81gm4RdzfppkhA, lenb-DgEjT+Ai2ygdnm+yROfE0A,
catalin.marinas-5wv7dgnIgG8, arnd-r2nGTMty4D4,
linux-arch-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
In-Reply-To: <58E5DF13.2020700-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Frank,
On 06/04/17 07:24, Frank Rowand wrote:
> On 04/04/17 03:18, Sricharan R wrote:
>> From: Laurent Pinchart <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>>
>> Invalid dma-ranges values should be worked around when retrieving the
>> DMA range in of_dma_get_range(), not by all callers of the function.
>> This isn't much of a problem now that we have a single caller, but that
>> situation will change when moving DMA configuration to device probe
>> time.
>
> Please drop this patch from the series. I just now sent Rob an
> alternative that reflects other changes that have occurred since
> this patch series was first created many, many moons ago
> (https://lkml.org/lkml/2017/4/6/53).
Fine by me too - if we can get rid of that dubious fixup altogether, all
the better. Feel free to transfer my Reviewed-by to your patch if you like.
Thanks,
Robin.
> Thanks,
>
> Frank
>
>>
>> Tested-by: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>> ---
>> drivers/of/address.c | 20 ++++++++++++++++++--
>> drivers/of/device.c | 15 ---------------
>> 2 files changed, 18 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>> index 02b2903..6aeb816 100644
>> --- a/drivers/of/address.c
>> +++ b/drivers/of/address.c
>> @@ -819,8 +819,8 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
>> * CPU addr (phys_addr_t) : pna cells
>> * size : nsize cells
>> *
>> - * It returns -ENODEV if "dma-ranges" property was not found
>> - * for this device in DT.
>> + * Return 0 on success, -ENODEV if the "dma-ranges" property was not found for
>> + * this device in DT, or -EINVAL if the CPU address or size is invalid.
>> */
>> int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
>> {
>> @@ -880,6 +880,22 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
>> *dma_addr = dmaaddr;
>>
>> *size = of_read_number(ranges + naddr + pna, nsize);
>> + /*
>> + * DT nodes sometimes incorrectly set the size as a mask. Work around
>> + * those incorrect DT by computing the size as mask + 1.
>> + */
>> + if (*size & 1) {
>> + pr_warn("%s: size 0x%llx for dma-range in node(%s) set as mask\n",
>> + __func__, *size, np->full_name);
>> + *size = *size + 1;
>> + }
>> +
>> + if (!*size) {
>> + pr_err("%s: invalid size zero for dma-range in node(%s)\n",
>> + __func__, np->full_name);
>> + ret = -EINVAL;
>> + goto out;
>> + }
>>
>> pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
>> *dma_addr, *paddr, *size);
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index b1e6beb..09dedd0 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -110,21 +110,6 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> size = dev->coherent_dma_mask + 1;
>> } else {
>> offset = PFN_DOWN(paddr - dma_addr);
>> -
>> - /*
>> - * Add a work around to treat the size as mask + 1 in case
>> - * it is defined in DT as a mask.
>> - */
>> - if (size & 1) {
>> - dev_warn(dev, "Invalid size 0x%llx for dma-range\n",
>> - size);
>> - size = size + 1;
>> - }
>> -
>> - if (!size) {
>> - dev_err(dev, "Adjusted size 0x%llx invalid\n", size);
>> - return;
>> - }
>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>> }
>>
>>
^ permalink raw reply
* Re: [PATCH V8 0/4] phy: USB and PCIe phy drivers for Qcom chipsets
From: Kishon Vijay Abraham I @ 2017-04-06 10:11 UTC (permalink / raw)
To: Vivek Gautam, robh+dt
Cc: mark.rutland, devicetree, linux-arm-msm, linux-usb, sboyd,
linux-kernel, bjorn.andersson, srinivas.kandagatla,
linux-arm-kernel
In-Reply-To: <1491457885-5254-1-git-send-email-vivek.gautam@codeaurora.org>
On Thursday 06 April 2017 11:21 AM, Vivek Gautam wrote:
> Hi Kishon,
> Here's the series with fixed checkpatch warnings/checks.
> Please pick it for phy/next.
>
> This patch series adds couple of PHY drivers for Qualcomm chipsets.
> a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
> b) qcom-qmp phy driver: that is a combo phy providing support for
> USB3, PCIe, UFS and few other controllers.
>
> The patches are based on next branch of linux-phy tree.
>
> These patches have been tested on Dragon board db820c hardware with
> required set of dt patches.
> The tested branch[3] is based on torvald's master with greg's usb/usb-next
> merged. Additionally the patches to get rpm up on msm8996 are also pulled
> in.
merged, thanks!
-Kishon
>
> Changes since v7:
> - Fixed 'checkpatch --strict' alignment warnings/checks, and
> added Stephen's Reviewed-by tag.
>
> Changes since v6:
> - Rebased on phy/next and *not* including phy grouping series[4].
> - qusb2-phy: addressed Stephen's comment.
> - Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
> - qmp-phy: none on functionality side.
>
> Changes since v5:
> - Addressed review comments from Bjorn:
> - Removed instances of readl/wirtel_relaxed calls from the drivers.
> Instead, using simple readl/writel. Inserting a readl after a writel
> to ensure the write is through to the device.
> - Replaced regulator handling with regulator_bulk_** apis. This helps
> in cutting down a lot of regulator handling code.
> - Fixed minor return statements.
>
> Changes since v4:
> - Addressed comment to add child nodes for qmp phy driver. Each phy lane
> now has a separate child node under the main qmp node.
> - Modified the clock and reset initialization and enable methods.
> Different phys - pcie, usb and later ufs, have varying number of clocks
> and resets that are mandatory. So adding provision for clocks and reset
> lists helps in requesting all mandatory resources for individual phys
> and handle their failure cases accordingly.
>
> Changes since v3:
> - Addressed review comments given by Rob and Stephen for qusb2 phy
> and qmp phy bindings respectively.
> - Addressed review comments given by Stephen and Bjorn for qmp phy driver.
>
> Changes since v2:
> - Addressed review comments given by Rob and Stephen for bindings.
> - Addressed the review comments given by Stephen for the qusb2 and qmp
> phy drivers.
>
> Changes since v1:
> - Moved device tree binding documentation to separate patches, as suggested
> by Rob.
> - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
> given by Rob.
> - Addressed review comments from Kishon.
> - Addressed review comments from Srinivas for QMP phy driver.
> - Addressed kbuild warning.
>
> Please see individual patches for detailed changelogs.
>
> [1] https://patchwork.kernel.org/patch/9567767/
> [2] https://patchwork.kernel.org/patch/9567779/
> [3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
> [4] https://lkml.org/lkml/2017/3/20/407
>
> Vivek Gautam (4):
> dt-bindings: phy: Add support for QUSB2 phy
> phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
> dt-bindings: phy: Add support for QMP phy
> phy: qcom-qmp: new qmp phy driver for qcom-chipsets
>
> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 106 ++
> .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 43 +
> drivers/phy/Kconfig | 18 +
> drivers/phy/Makefile | 2 +
> drivers/phy/phy-qcom-qmp.c | 1153 ++++++++++++++++++++
> drivers/phy/phy-qcom-qusb2.c | 493 +++++++++
> 6 files changed, 1815 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
> create mode 100644 drivers/phy/phy-qcom-qmp.c
> create mode 100644 drivers/phy/phy-qcom-qusb2.c
>
^ permalink raw reply
* Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask
From: Robin Murphy @ 2017-04-06 10:24 UTC (permalink / raw)
To: Frank Rowand, Sricharan R, will.deacon-5wv7dgnIgG8,
joro-zLv9SwRftAIdnm+yROfE0A, lorenzo.pieralisi-5wv7dgnIgG8,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, tn-nYOzD4b6Jr9Wk0Htik3J/w,
hanjun.guo-QSEj5FYQhm4dnm+yROfE0A, okaya-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, sudeep.holla-5wv7dgnIgG8,
rjw-LthD3rsA81gm4RdzfppkhA, lenb-DgEjT+Ai2ygdnm+yROfE0A,
catalin.marinas-5wv7dgnIgG8, arnd-r2nGTMty4D4,
linux-arch-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
In-Reply-To: <58E5E7B7.1050400-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 06/04/17 08:01, Frank Rowand wrote:
> On 04/04/17 03:18, Sricharan R wrote:
>> Size of the dma-range is calculated as coherent_dma_mask + 1
>> and passed to arch_setup_dma_ops further. It overflows when
>> the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF,
>> resulting in size getting passed as 0 wrongly. Fix this by
>> passsing in max(mask, mask + 1). Note that in this case
>> when the mask is set to full 64bits, we will be passing the mask
>> itself to arch_setup_dma_ops instead of the size. The real fix
>> for this should be to make arch_setup_dma_ops receive the
>> mask and handle it, to be done in the future.
>>
>> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> drivers/of/device.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index c17c19d..c2ae6bb 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>> if (ret < 0) {
>> dma_addr = offset = 0;
>> - size = dev->coherent_dma_mask + 1;
>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>> } else {
>> offset = PFN_DOWN(paddr - dma_addr);
>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>>
>
> NACK.
>
> Passing an invalid size to arch_setup_dma_ops() is only part of the problem.
> size is also used in of_dma_configure() before calling arch_setup_dma_ops():
>
> dev->coherent_dma_mask = min(dev->coherent_dma_mask,
> DMA_BIT_MASK(ilog2(dma_addr + size)));
> *dev->dma_mask = min((*dev->dma_mask),
> DMA_BIT_MASK(ilog2(dma_addr + size)));
>
> which would be incorrect for size == 0xffffffffffffffffULL when
> dma_addr != 0. So the proposed fix really is not papering over
> the base problem very well.
I'm not sure I agree there. Granted, there exist many more problematic
aspects than are dealt with here (I've got more patches cooking to sort
out some of the other issues we have with dma-ranges), but considering
size specifically:
- It is not possible to explicitly specify a range with a size of 2^64
in DT. If someone does specify a size of 0, they've done a silly thing
and should not be surprised that it ends badly.
- It *is* perfectly legitimate for bus code (or a previous device
driver, once we start coming here at probe time) to have set a device's
DMA mask to 0xffffffffffffffffULL. If this code then blindly overflows
and infers an invalid size of 0 from that, breaking things in the
process, that is this code's fault alone. It just so happens that
nothing managed to trigger the latent problem until patch #7 here shakes
up the callsites.
Yes, wacky impossible base + size combinations in DT were a theoretical
problem before, and remain a theoretical problem, but also fall into the
"how did you ever expect this to work?" category. There's certainly
plenty more we can do to improve the DT parsing/validation, but that
still doesn't apply to this path where the information is *not* coming
from the DT at all.
> I agree that the proper solution involves passing a mask instead
> of a size to arch_setup_dma_ops().
Having started writing that patch too, I can tell you it's a big bugger
touching multiple architectures and fixing up various drivers doing
stupid things, hence why I'm happy with this point fix being the lesser
of two evils in terms of not holding up this mostly-orthogonal series.
Robin.
>
> -Frank
>
^ permalink raw reply
* Re: [PATCH 0/2] pmu0 MMIO region for A64 USB PHY
From: Kishon Vijay Abraham I @ 2017-04-06 10:26 UTC (permalink / raw)
To: Icenowy Zheng, Maxime Ripard, Chen-Yu Tsai, Greg Kroah-Hartman
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405143034.8868-1-icenowy-h8G6r0blFSE@public.gmane.org>
Hi,
On Wednesday 05 April 2017 08:00 PM, Icenowy Zheng wrote:
> The USB PHY of A64 contains a "pmu0" MMIO region, which contains some control
> registers for the EHCI0/OHCI0 pair on A64 SoC.
>
> This pair is not used currently in 4.11, but when enabling it in 4.12, the
> MMIO region is needed.
>
> In order to prevent device tree compatibility breakage, add this region in
> 4.11.
I feel the binding documentation can go along with the dt changes. Moreover I
have no plans of sending another pull request for this -rc cycle.
FWIW:
Acked-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Thanks
Kishon
>
> Icenowy Zheng (2):
> dt: bindings: add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64
> arm64: allwinner: a64: add pmu0 regs for USB PHY
>
> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 ++
> 2 files changed, 3 insertions(+)
>
^ permalink raw reply
* Re: [PATCH v5 1/9] phy: phy-mt65xx-usb3: improve RX detection stable time
From: Kishon Vijay Abraham I @ 2017-04-06 10:28 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland, devicetree, Felipe Balbi, Ian Campbell, linux-usb,
linux-kernel, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
In-Reply-To: <1490945735-9531-1-git-send-email-chunfeng.yun@mediatek.com>
On Friday 31 March 2017 01:05 PM, Chunfeng Yun wrote:
> The default value of RX detection stable time is 10us, and this
> margin is too big for some critical cases which cause U3 link fail
> and link to U2(probability is about 1%). So change it to 5us.
>
merged all the phy patches in this series to linux-phy -next.
Thanks
Kishon
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> drivers/phy/phy-mt65xx-usb3.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> index d972067..fe2392a 100644
> --- a/drivers/phy/phy-mt65xx-usb3.c
> +++ b/drivers/phy/phy-mt65xx-usb3.c
> @@ -112,6 +112,14 @@
> #define P3D_RG_CDR_BIR_LTD0 GENMASK(12, 8)
> #define P3D_RG_CDR_BIR_LTD0_VAL(x) ((0x1f & (x)) << 8)
>
> +#define U3P_U3_PHYD_RXDET1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x128)
> +#define P3D_RG_RXDET_STB2_SET GENMASK(17, 9)
> +#define P3D_RG_RXDET_STB2_SET_VAL(x) ((0x1ff & (x)) << 9)
> +
> +#define U3P_U3_PHYD_RXDET2 (SSUSB_SIFSLV_U3PHYD_BASE + 0x12c)
> +#define P3D_RG_RXDET_STB2_SET_P3 GENMASK(8, 0)
> +#define P3D_RG_RXDET_STB2_SET_P3_VAL(x) (0x1ff & (x))
> +
> #define U3P_XTALCTL3 (SSUSB_SIFSLV_SPLLC + 0x0018)
> #define XC3_RG_U3_XTAL_RX_PWD BIT(9)
> #define XC3_RG_U3_FRC_XTAL_RX_PWD BIT(8)
> @@ -295,6 +303,16 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
> tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3);
> writel(tmp, port_base + U3P_PHYD_CDR1);
>
> + tmp = readl(port_base + U3P_U3_PHYD_RXDET1);
> + tmp &= ~P3D_RG_RXDET_STB2_SET;
> + tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10);
> + writel(tmp, port_base + U3P_U3_PHYD_RXDET1);
> +
> + tmp = readl(port_base + U3P_U3_PHYD_RXDET2);
> + tmp &= ~P3D_RG_RXDET_STB2_SET_P3;
> + tmp |= P3D_RG_RXDET_STB2_SET_P3_VAL(0x10);
> + writel(tmp, port_base + U3P_U3_PHYD_RXDET2);
> +
> dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
> }
>
>
^ permalink raw reply
* [RFC] Documentation: pinctrl: Add "pinmux" property
From: Jacopo Mondi @ 2017-04-06 10:35 UTC (permalink / raw)
To: linus.walleij, geert, robh+dt, mark.rutland
Cc: linux-gpio, devicetree, linux-renesas-soc, linux-kernel
Document "pinmux" property as part of generic pin controller
documentation.
Fix 2 minor typos in documentation while at there.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
Hi Linus and linux-gpio community.
During development of Renesas RZ/A1 pin controller I've been suggested to add
description of "pinmux" property to generic pin controller documentation.
Currently several pin controller drivers are using this property in place of
the already documented "pin"/"group" and "function" ones: stm32, mt65xx, mt8173
and in-review r7s72100, not sure about at91-sama5d2)
Sending this one as RFC to collect feedback. If the change is not rejected is it
worth adding to pin controller core helper functions to parse the newly
documented property, as this commit
<https://patchwork.kernel.org/patch/9411231/>
did for "pinctrl-pin-array" one?
All drivers using "pinmux" exhibit the same behavior which is fine as long as
"pinmux" only accepts a list of u32 parameters.
...
pins = of_find_property(node, "pinmux", NULL);
...
npins = pins->length / sizeof(u32);
...
of_property_read_u32_index(node, "pinmux",
i, &pinfunc);
...
Thanks
---
.../bindings/pinctrl/pinctrl-bindings.txt | 46 +++++++++++++++++++---
1 file changed, 41 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index f2ed458..6609389 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -162,8 +162,8 @@ state_2_node_a {
pins = "mfio29", "mfio30";
};
-Optionally an altenative binding can be used if more suitable depending on the
-pin controller hardware. For hardaware where there is a large number of identical
+Optionally an alternative binding can be used if more suitable depending on the
+pin controller hardware. For hardware where there is a large number of identical
pin controller instances, naming each pin and function can easily become
unmaintainable. This is especially the case if the same controller is used for
different pins and functions depending on the SoC revision and packaging.
@@ -198,6 +198,28 @@ registers, and must not be a virtual index of pin instances. The reason for
this is to avoid mapping of the index in the dts files and the pin controller
driver as it can change.
+For hardware where pin multiplexing configurations have to be specified for
+each single pin the number of required sub-nodes containing "pin" and
+"function" properties can quickly escalate and become hard to write and
+maintain.
+
+For cases like this, the pin controller driver may use the pinmux helper
+property, where the pin identifier is packed with mux configuration settings
+in a single integer.
+
+The pinmux property accepts an array of integers, each of them describing
+a single pin multiplexing configuration.
+
+pincontroller {
+ state_0_node_a {
+ pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ...;
+ };
+};
+
+Each individual pin controller driver bindings documentation shall specify
+how those values (pin IDs and pin multiplexing configuration) are defined and
+assembled together.
+
== Generic pin configuration node content ==
Many data items that are represented in a pin configuration node are common
@@ -210,12 +232,15 @@ structure of the DT nodes that contain these properties.
Supported generic properties are:
pins - the list of pins that properties in the node
- apply to (either this or "group" has to be
+ apply to (either this, "group" or "pinmux" has to be
specified)
group - the group to apply the properties to, if the driver
supports configuration of whole groups rather than
- individual pins (either this or "pins" has to be
- specified)
+ individual pins (either this, "pins" or "pinmux" has
+ to be specified)
+pinmux - the list of numeric pin ids and their mux settings
+ that properties in the node apply to (either this,
+ "pins" or "groups" have to be specified)
bias-disable - disable any pin bias
bias-high-impedance - high impedance mode ("third-state", "floating")
bias-bus-hold - latch weakly
@@ -260,6 +285,12 @@ state_2_node_a {
bias-pull-up;
};
};
+state_3_node_a {
+ mux {
+ pinmux = <GPIOx_PINm_MUXn>, <GPIOx_PINj_MUXk)>;
+ input-enable;
+ };
+};
Some of the generic properties take arguments. For those that do, the
arguments are described below.
@@ -268,6 +299,11 @@ arguments are described below.
binding for the hardware defines:
- Whether the entries are integers or strings, and their meaning.
+- pinmux takes a list of pin IDs and mux settings as required argument. The
+ specific bindings for the hardware defines:
+ - How pin IDs and mux settings are defined and assembled together in a single
+ integer.
+
- bias-pull-up, -down and -pin-default take as optional argument on hardware
supporting it the pull strength in Ohm. bias-disable will disable the pull.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/3] phy: rockchip-usb: Add vbus regulator support.
From: Kishon Vijay Abraham I @ 2017-04-06 10:37 UTC (permalink / raw)
To: Sjoerd Simons, John Youn, Heiko Stuebner
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Randy Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170405140613.4444-2-sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
On Wednesday 05 April 2017 07:36 PM, Sjoerd Simons wrote:
> On rockchip devices vbus is supplied by a separate power supply, often
> through a regulator. Add support for describing the the regulator in
> device-tree following the same convention as several other usb phy's.
>
merged, thanks.
-Kishon
> Signed-off-by: Sjoerd Simons <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> ---
>
> .../devicetree/bindings/phy/rockchip-usb-phy.txt | 1 +
> drivers/phy/phy-rockchip-usb.c | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
> index 57dc388e2fa2..4ed569046daf 100644
> --- a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
> @@ -30,6 +30,7 @@ Optional Properties:
> - reset-names: Only allow the following entries:
> - phy-reset
> - resets: Must contain an entry for each entry in reset-names.
> +- vbus-supply: power-supply phandle for vbus power source
>
> Example:
>
> diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
> index 734987fa0ad7..3378eeb7a562 100644
> --- a/drivers/phy/phy-rockchip-usb.c
> +++ b/drivers/phy/phy-rockchip-usb.c
> @@ -66,6 +66,7 @@ struct rockchip_usb_phy {
> struct phy *phy;
> bool uart_enabled;
> struct reset_control *reset;
> + struct regulator *vbus;
> };
>
> static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
> @@ -88,6 +89,9 @@ static void rockchip_usb_phy480m_disable(struct clk_hw *hw)
> struct rockchip_usb_phy,
> clk480m_hw);
>
> + if (phy->vbus)
> + regulator_disable(phy->vbus);
> +
> /* Power down usb phy analog blocks by set siddq 1 */
> rockchip_usb_phy_power(phy, 1);
> }
> @@ -143,6 +147,14 @@ static int rockchip_usb_phy_power_on(struct phy *_phy)
> if (phy->uart_enabled)
> return -EBUSY;
>
> + if (phy->vbus) {
> + int ret;
> +
> + ret = regulator_enable(phy->vbus);
> + if (ret)
> + return ret;
> + }
> +
> return clk_prepare_enable(phy->clk480m);
> }
>
> @@ -268,6 +280,13 @@ static int rockchip_usb_phy_init(struct rockchip_usb_phy_base *base,
> }
> phy_set_drvdata(rk_phy->phy, rk_phy);
>
> + rk_phy->vbus = devm_regulator_get_optional(&rk_phy->phy->dev, "vbus");
> + if (IS_ERR(rk_phy->vbus)) {
> + if (PTR_ERR(rk_phy->vbus) == -EPROBE_DEFER)
> + return PTR_ERR(rk_phy->vbus);
> + rk_phy->vbus = NULL;
> + }
> +
> /*
> * When acting as uart-pipe, just keep clock on otherwise
> * only power up usb phy when it use, so disable it when init
>
^ permalink raw reply
* Re: [PATCH v5 1/9] phy: phy-mt65xx-usb3: improve RX detection stable time
From: Chunfeng Yun @ 2017-04-06 10:49 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Matthias Brugger, Felipe Balbi, Rob Herring, Mark Rutland,
Ian Campbell, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <de1b9870-d325-e97a-a2f0-bd355c70356c-l0cyMroinI0@public.gmane.org>
On Thu, 2017-04-06 at 15:58 +0530, Kishon Vijay Abraham I wrote:
>
> On Friday 31 March 2017 01:05 PM, Chunfeng Yun wrote:
> > The default value of RX detection stable time is 10us, and this
> > margin is too big for some critical cases which cause U3 link fail
> > and link to U2(probability is about 1%). So change it to 5us.
> >
> merged all the phy patches in this series to linux-phy -next.
Thanks a lot
>
> Thanks
> Kishon
>
> > Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/phy/phy-mt65xx-usb3.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> > index d972067..fe2392a 100644
> > --- a/drivers/phy/phy-mt65xx-usb3.c
> > +++ b/drivers/phy/phy-mt65xx-usb3.c
> > @@ -112,6 +112,14 @@
> > #define P3D_RG_CDR_BIR_LTD0 GENMASK(12, 8)
> > #define P3D_RG_CDR_BIR_LTD0_VAL(x) ((0x1f & (x)) << 8)
> >
> > +#define U3P_U3_PHYD_RXDET1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x128)
> > +#define P3D_RG_RXDET_STB2_SET GENMASK(17, 9)
> > +#define P3D_RG_RXDET_STB2_SET_VAL(x) ((0x1ff & (x)) << 9)
> > +
> > +#define U3P_U3_PHYD_RXDET2 (SSUSB_SIFSLV_U3PHYD_BASE + 0x12c)
> > +#define P3D_RG_RXDET_STB2_SET_P3 GENMASK(8, 0)
> > +#define P3D_RG_RXDET_STB2_SET_P3_VAL(x) (0x1ff & (x))
> > +
> > #define U3P_XTALCTL3 (SSUSB_SIFSLV_SPLLC + 0x0018)
> > #define XC3_RG_U3_XTAL_RX_PWD BIT(9)
> > #define XC3_RG_U3_FRC_XTAL_RX_PWD BIT(8)
> > @@ -295,6 +303,16 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
> > tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3);
> > writel(tmp, port_base + U3P_PHYD_CDR1);
> >
> > + tmp = readl(port_base + U3P_U3_PHYD_RXDET1);
> > + tmp &= ~P3D_RG_RXDET_STB2_SET;
> > + tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10);
> > + writel(tmp, port_base + U3P_U3_PHYD_RXDET1);
> > +
> > + tmp = readl(port_base + U3P_U3_PHYD_RXDET2);
> > + tmp &= ~P3D_RG_RXDET_STB2_SET_P3;
> > + tmp |= P3D_RG_RXDET_STB2_SET_P3_VAL(0x10);
> > + writel(tmp, port_base + U3P_U3_PHYD_RXDET2);
> > +
> > dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
> > }
> >
> >
--
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 07/16] regulator: madera-micsupp: Mic supply for Cirrus Logic Madera codecs
From: Mark Brown @ 2017-04-06 10:57 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: gnurou, alsa-devel, jason, devicetree, linus.walleij, patches,
linux-kernel, linux-gpio, robh+dt, tglx, lee.jones
In-Reply-To: <1491400437.4096.5.camel@rf-debian.wolfsonmicro.main>
[-- Attachment #1.1: Type: text/plain, Size: 650 bytes --]
On Wed, Apr 05, 2017 at 02:53:57PM +0100, Richard Fitzgerald wrote:
> On Wed, 2017-04-05 at 14:40 +0100, Mark Brown wrote:
> > Again, this appears to have only data and minor code style changes
> > relative to the existing arizona driver - is there no opportunity for
> > code sharing here?
> I'll have a look at how it would work out.
> My thought was that these two regulator drivers are so small it wasn't
> worth creating an entanglement between arizona and madera for so little
> code.
It's a fairly small amount of code but it's an extremely high proportion
of the code in the driver and doing something a bit unusual, not just
boilerplate.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ 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