* [PATCH V2 0/2] pinctrl: tegra: Add support for IO pad control
From: Laxman Dewangan @ 2016-11-09 13:06 UTC (permalink / raw)
To: linus.walleij, robh+dt, mark.rutland, swarren, thierry.reding
Cc: gnurou, yamada.masahiro, jonathanh, linux-gpio, devicetree,
linux-tegra, linux-kernel, Laxman Dewangan
NVIDIA Tegra124 and later SoCs support the multi-voltage level and
low power state of some of its IO pads. The IO pads can work in
the voltage of the 1.8V and 3.3V of IO power rail sources. When IO
interface are not used then IO pads can be configure in low power
state to reduce the power from that IO pads.
This series add the support of configuration of IO pad via pinctrl
framework. The io pad driver uses the tegra PMC interface.
---
This driver was sent earlier for review along with soc/tegra pmc
changes. During review, decided to first conclude in soc/tegra pmc
patches and then review this.
Thierry applied the pmc patches in the private tree
https://github.com/thierryreding/linux/tree/tegra186
and he wanted to have the patches for user of the new APIs so that
it can be pushed to mainline.
Sending the pinctrl driver. This needs Ack/reviewed from pinctrl subsystem
i.e. Linus Welleij to apply in the Thierry's T186 branch along with
PMC patches.
---
Changes from V1:
- use the regulator framework to get the IO voltage instead of table from
DT. The regulator handle is provided from DT.
Laxman Dewangan (2):
pinctrl: tegra: Add DT binding for io pads control
pinctrl: tegra: Add driver to configure voltage and power of io pads
.../bindings/pinctrl/nvidia,tegra-io-pad.txt | 112 +++++++
drivers/pinctrl/tegra/Kconfig | 12 +
drivers/pinctrl/tegra/Makefile | 1 +
drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c | 369 +++++++++++++++++++++
include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h | 21 ++
5 files changed, 515 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
create mode 100644 include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h
--
2.1.4
^ permalink raw reply
* [PATCH V2 1/2] pinctrl: tegra: Add DT binding for io pads control
From: Laxman Dewangan @ 2016-11-09 13:06 UTC (permalink / raw)
To: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
swarren-3lzwWm7+Weoh9ZMKESR00Q,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w
Cc: gnurou-Re5JQEeQqe8AvxtiuMwx3w,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
jonathanh-DDmLM1+adcrQT0dZR+AlfA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Laxman Dewangan
In-Reply-To: <1478696782-11657-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
NVIDIA Tegra124 and later SoCs support the multi-voltage level and
low power state of some of its IO pads. The IO pads can work in
the voltage of the 1.8V and 3.3V of IO voltage from IO power rail
sources. When IO interfaces are not used then IO pads can be
configure in low power state to reduce the power consumption from
that IO pads.
On Tegra124, the voltage level of IO power rail source is auto
detected by hardware(SoC) and hence it is only require to configure
in low power mode if IO pads are not used.
On T210 onwards, the auto-detection of voltage level from IO power
rail is removed from SoC and hence SW need to configure the PMC
register explicitly to set proper voltage in IO pads based on
IO rail power source voltage.
Add DT binding document for detailing the DT properties for
configuring IO pads voltage levels and its power state.
Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Changes from V1:
The DT binding document is modified to explain the regulator handle
for different IOs and how can it be passed from the DT.
---
.../bindings/pinctrl/nvidia,tegra-io-pad.txt | 126 +++++++++++++++++++++
1 file changed, 126 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
new file mode 100644
index 0000000..6ca961f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
@@ -0,0 +1,126 @@
+NVIDIA Tegra PMC IO pad controller
+
+NVIDIA Tegra124 and later SoCs support the multi-voltage level and
+low power state of some of its IO pads. When IO interface are not
+used then IO pads can be configure in low power state to reduce
+the power from that IO pads. The IO pads can work in the voltage
+of the 1.8V and 3.3V of IO voltage from power rail sources.
+
+On Tegra124, the voltage of IO power rail source is auto detected by
+SoC and hence it is only require to configure in low power mode if
+IO pads are not used.
+
+On T210 onwards, the HW based auto-detection for IO voltage is removed
+and hence SW need to configure the PMC register explicitly, to set proper
+voltage in IO pads, based on IO rail power source voltage.
+
+The voltage configurations and low power state of IO pads should be done
+in boot if it is not going to change other wise dynamically based on IO
+rail voltage on that IO pads and usage of IO pads
+
+The DT property of the io pads must be under the node of pmc i.e.
+pmc@7000e400 for Tegra124 onwards.
+
+Please refer to <pinctrl-bindings.txt> in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Tegra's pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for an
+IO pads, or a list of IO pads. This configuration can include the voltage and
+power enable/disable control
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content. Each subnode only affects those
+parameters that are explicitly listed. Unspecified is represented as an absent
+property,
+
+See the TRM to determine which properties and values apply to each IO pads.
+
+Required subnode-properties:
+==========================
+- pins : An array of strings. Each string contains the name of an IO pads. Valid
+ values for these names are listed below.
+
+Optional subnode-properties:
+==========================
+Following properties are supported from generic pin configuration explained
+in <dt-bindings/pinctrl/pinctrl-binding.txt>.
+low-power-enable: enable low power mode.
+low-power-disable: disable low power mode.
+
+Valid values for pin for T124 are:
+ audio, bb, cam, comp, csia, csib, csie, dsi, dsib, dsic, dsid, hdmi,
+ hsic, hv, lvds, mipi-bias, nand, pex-bias, pex-clk1, pex-clk2,
+ pex-ctrl, sdmmc1, sdmmc3, sdmmc4, sys-ddc, uart, usb0, usb1, usb2,
+ usb-bias
+
+Valid values for pin for T210 are:
+ audio, audio-hv, cam, csia, csib, csic, csid, csie, csif,
+ dbg, debug-nonao, dmic, dp, dsi, dsib, dsic, dsid, emmc, emmc2,
+ gpio, hdmi, hsic, lvds, mipi-bias, pex-bias, pex-clk1, pex-clk2,
+ pex-ctrl, sdmmc1, sdmmc3, spi, spi-hv, uart, usb-bias, usb0,
+ usb1, usb2, usb3.
+
+To find out the IO rail voltage for setting the voltage of IO pad by SW,
+the regulator supply handle must provided from the DT and it is explained
+in the regulator DT binding document
+ <devicetree/bindings/regulator/regulator.txt>.
+For example, for GPIO rail the supply name is vddio-gpio and regulator
+handle is supplied from DT as
+ vddio-gpio-supply = <®ulator_xyz>;
+
+For T210, following IO pads support the 1.8V/3.3V and the corresponding
+io voltage pin names are as follows:
+ audio -> vddio-audio
+ audio-hv -> vddio-audio-hv
+ cam ->vddio-cam
+ dbg -> vddio-dbg
+ dmic -> vddio-dmic
+ gpio -> vddio-gpio
+ pex-ctrl -> vddio-pex-ctrl
+ sdmmc1 -> vddio-sdmmc1
+ sdmmc3 -> vddio-sdmmc3
+ spi -> vddio-spi
+ spi-hv -> vddio-spi-hv
+ uart -> vddio-uart
+
+Example:
+ i2c@7000d000 {
+ pmic@3c {
+ regulators {
+ vddio_sdmmc1: ldo2 {
+ /* Regulator entries for LDO2 */
+ };
+
+ vdd_cam: ldo3 {
+ /* Regulator entries for LDO3 */
+ };
+ };
+ };
+ };
+
+ pmc@7000e400 {
+ vddio-cam = <&vdd_cam>;
+ vddio-sdmmc1-supply = <&vddio_sdmmc1>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tegra_io_pad_volt_default>;
+ tegra_io_pad_volt_default: common {
+ audio-hv {
+ pins = "audio-hv";
+ low-power-disable;
+ };
+
+ gpio {
+ pins = "gpio";
+ low-power-disable;
+ };
+
+ audio {
+ pins = "audio", "dmic", "sdmmc3";
+ low-power-enable;
+ };
+ };
+
+ };
--
2.1.4
^ permalink raw reply related
* [PATCH V2 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Laxman Dewangan @ 2016-11-09 13:06 UTC (permalink / raw)
To: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
swarren-3lzwWm7+Weoh9ZMKESR00Q,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w
Cc: gnurou-Re5JQEeQqe8AvxtiuMwx3w,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
jonathanh-DDmLM1+adcrQT0dZR+AlfA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Laxman Dewangan
In-Reply-To: <1478696782-11657-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
NVIDIA Tegra124 and later SoCs support the multi-voltage level and
low power state of some of its IO pads. The IO pads can work in
the voltage of the 1.8V and 3.3V of IO voltage from IO power rail
sources. When IO interfaces are not used then IO pads can be
configure in low power state to reduce the power consumption from
that IO pads.
On Tegra124, the voltage level of IO power rail source is auto
detected by hardware(SoC) and hence it is only require to configure
in low power mode if IO pads are not used.
On T210 onwards, the auto-detection of voltage level from IO power
rail is removed from SoC and hence SW need to configure the PMC
register explicitly to set proper voltage in IO pads based on
IO rail power source voltage.
This driver adds the IO pad driver to configure the power state and
IO pad voltage based on the usage and power tree via pincontrol
framework. The configuration can be static and dynamic.
Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Changes from V1:
- Dropped the custom properties to set pad voltage and use regulator.
- Added support for regulator to get vottage in boot and configure IO
pad voltage.
- Add support for callback to handle regulator notification and configure
IO pad voltage based on voltage change.
---
drivers/pinctrl/tegra/Kconfig | 12 +
drivers/pinctrl/tegra/Makefile | 1 +
drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c | 488 +++++++++++++++++++++++++++
3 files changed, 501 insertions(+)
create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
diff --git a/drivers/pinctrl/tegra/Kconfig b/drivers/pinctrl/tegra/Kconfig
index 24e20cc..6004e5c 100644
--- a/drivers/pinctrl/tegra/Kconfig
+++ b/drivers/pinctrl/tegra/Kconfig
@@ -23,6 +23,18 @@ config PINCTRL_TEGRA210
bool
select PINCTRL_TEGRA
+config PINCTRL_TEGRA_IO_PAD
+ bool "Tegra IO pad Control Driver"
+ depends on ARCH_TEGRA && REGULATOR
+ select PINCONF
+ select PINMUX
+ help
+ NVIDIA Tegra124/210 SoC has IO pads which supports multi-voltage
+ level of interfacing and deep power down mode of IO pads. The
+ voltage of IO pads are SW configurable based on IO rail of that
+ pads on T210. This driver provides the interface to change IO pad
+ voltage and power state via pincontrol interface.
+
config PINCTRL_TEGRA_XUSB
def_bool y if ARCH_TEGRA
select GENERIC_PHY
diff --git a/drivers/pinctrl/tegra/Makefile b/drivers/pinctrl/tegra/Makefile
index d9ea2be..3ebaaa2 100644
--- a/drivers/pinctrl/tegra/Makefile
+++ b/drivers/pinctrl/tegra/Makefile
@@ -4,4 +4,5 @@ obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
obj-$(CONFIG_PINCTRL_TEGRA114) += pinctrl-tegra114.o
obj-$(CONFIG_PINCTRL_TEGRA124) += pinctrl-tegra124.o
obj-$(CONFIG_PINCTRL_TEGRA210) += pinctrl-tegra210.o
+obj-$(CONFIG_PINCTRL_TEGRA_IO_PAD) += pinctrl-tegra-io-pad.o
obj-$(CONFIG_PINCTRL_TEGRA_XUSB) += pinctrl-tegra-xusb.o
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c b/drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
new file mode 100644
index 0000000..f5cf0d0
--- /dev/null
+++ b/drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
@@ -0,0 +1,488 @@
+/*
+ * pinctrl-tegra-io-pad: IO PAD driver for configuration of IO rail and deep
+ * Power Down mode via pinctrl framework.
+ *
+ * Copyright (C) 2016 NVIDIA CORPORATION. All rights reserved.
+ *
+ * Author: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinmux.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <soc/tegra/pmc.h>
+
+#include "../core.h"
+#include "../pinconf.h"
+#include "../pinctrl-utils.h"
+
+/**
+ * Macro for 1.8V, keep 200mV as tolerance for deciding that
+ * IO pads should be set for 3.3V (high voltage) or 1.8V.
+ */
+#define TEGRA_IO_PAD_1800000UV_UPPER_LIMIT 2000000
+
+struct tegra_io_pads_cfg_info {
+ const char *name;
+ const unsigned int pins[1];
+ const char *vsupply;
+ enum tegra_io_pad pad_id;
+ bool support_low_power_state;
+};
+
+struct tegra_io_pad_soc_data {
+ const struct tegra_io_pads_cfg_info *pads_cfg;
+ int num_pads_cfg;
+ const struct pinctrl_pin_desc *pins_desc;
+ int num_pins_desc;
+};
+
+struct tegra_io_pads_regulator_info {
+ struct device *dev;
+ const struct tegra_io_pads_cfg_info *pads_cfg;
+ struct regulator *regulator;
+ struct notifier_block regulator_nb;
+};
+
+struct tegra_io_pads_info {
+ struct device *dev;
+ struct pinctrl_dev *pctl;
+ struct tegra_io_pads_regulator_info *rinfo;
+ const struct tegra_io_pad_soc_data *soc_data;
+};
+
+static int tegra_iop_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
+{
+ struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
+
+ return tiopi->soc_data->num_pads_cfg;
+}
+
+static const char *tegra_iop_pinctrl_get_group_name(struct pinctrl_dev *pctldev,
+ unsigned int group)
+{
+ struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
+
+ return tiopi->soc_data->pads_cfg[group].name;
+}
+
+static int tegra_iop_pinctrl_get_group_pins(struct pinctrl_dev *pctldev,
+ unsigned int group,
+ const unsigned int **pins,
+ unsigned int *num_pins)
+{
+ struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
+
+ *pins = tiopi->soc_data->pads_cfg[group].pins;
+ *num_pins = 1;
+
+ return 0;
+}
+
+static const struct pinctrl_ops tegra_iop_pinctrl_ops = {
+ .get_groups_count = tegra_iop_pinctrl_get_groups_count,
+ .get_group_name = tegra_iop_pinctrl_get_group_name,
+ .get_group_pins = tegra_iop_pinctrl_get_group_pins,
+ .dt_node_to_map = pinconf_generic_dt_node_to_map_pin,
+ .dt_free_map = pinctrl_utils_free_map,
+};
+
+static int tegra_io_pad_pinconf_get(struct pinctrl_dev *pctldev,
+ unsigned int pin, unsigned long *config)
+{
+ struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
+ int param = pinconf_to_config_param(*config);
+ const struct tegra_io_pads_cfg_info *pads_cfg =
+ &tiopi->soc_data->pads_cfg[pin];
+ enum tegra_io_pad pad_id = pads_cfg->pad_id;
+ int arg = 0;
+ int ret;
+
+ switch (param) {
+ case PIN_CONFIG_LOW_POWER_MODE:
+ ret = tegra_io_pad_power_get_status(pad_id);
+ if (ret < 0)
+ return ret;
+ arg = !ret;
+ break;
+
+ default:
+ dev_err(tiopi->dev, "The parameter %d not supported\n", param);
+ return -EINVAL;
+ }
+
+ *config = pinconf_to_config_packed(param, (u16)arg);
+ return 0;
+}
+
+static int tegra_io_pad_pinconf_set(struct pinctrl_dev *pctldev,
+ unsigned int pin, unsigned long *configs,
+ unsigned int num_configs)
+{
+ struct tegra_io_pads_info *tiopi = pinctrl_dev_get_drvdata(pctldev);
+ const struct tegra_io_pads_cfg_info *pads_cfg =
+ &tiopi->soc_data->pads_cfg[pin];
+ int pad_id = pads_cfg->pad_id;
+ u16 param_val;
+ int param;
+ int ret;
+ int i;
+
+ for (i = 0; i < num_configs; i++) {
+ param = pinconf_to_config_param(configs[i]);
+ param_val = pinconf_to_config_argument(configs[i]);
+
+ switch (param) {
+ case PIN_CONFIG_LOW_POWER_MODE:
+ if (param_val)
+ ret = tegra_io_pad_power_disable(pad_id);
+ else
+ ret = tegra_io_pad_power_enable(pad_id);
+ if (ret < 0) {
+ dev_err(tiopi->dev,
+ "Failed to set DPD %d of pin %u: %d\n",
+ param_val, pin, ret);
+ return ret;
+ }
+ break;
+
+ default:
+ dev_err(tiopi->dev, "The parameter %d not supported\n",
+ param);
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+static const struct pinconf_ops tegra_io_pad_pinconf_ops = {
+ .pin_config_get = tegra_io_pad_pinconf_get,
+ .pin_config_set = tegra_io_pad_pinconf_set,
+};
+
+static struct pinctrl_desc tegra_iop_pinctrl_desc = {
+ .name = "pinctrl-tegra-io-pads",
+ .pctlops = &tegra_iop_pinctrl_ops,
+ .confops = &tegra_io_pad_pinconf_ops,
+};
+
+static int tegra_io_pads_rail_change_notify_cb(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct tegra_io_pads_regulator_info *rinfo;
+ struct pre_voltage_change_data *vdata;
+ unsigned long int io_volt_uv, old_uv;
+ enum tegra_io_pad_voltage io_volt;
+ int ret;
+
+ rinfo = container_of(nb, struct tegra_io_pads_regulator_info,
+ regulator_nb);
+
+ switch (event) {
+ case REGULATOR_EVENT_PRE_VOLTAGE_CHANGE:
+ vdata = data;
+ if ((vdata->old_uV > TEGRA_IO_PAD_1800000UV_UPPER_LIMIT) &&
+ (vdata->min_uV <= TEGRA_IO_PAD_1800000UV_UPPER_LIMIT))
+ break;
+
+ ret = tegra_io_pad_set_voltage(rinfo->pads_cfg->pad_id,
+ TEGRA_IO_PAD_3300000UV);
+ if (ret < 0) {
+ dev_err(rinfo->dev,
+ "Failed to set voltage %lu of pad %s: %d\n",
+ vdata->min_uV, rinfo->pads_cfg->name, ret);
+ return ret;
+ }
+ break;
+
+ case REGULATOR_EVENT_VOLTAGE_CHANGE:
+ io_volt_uv = (unsigned long)data;
+ ret = tegra_io_pad_get_voltage(rinfo->pads_cfg->pad_id);
+ if (ret < 0) {
+ dev_err(rinfo->dev, "Failed to get IO pad voltage: %d\n",
+ ret);
+ return ret;
+ }
+ old_uv = (ret == TEGRA_IO_PAD_1800000UV) ? 1800000 : 3300000;
+ if (((io_volt_uv <= TEGRA_IO_PAD_1800000UV_UPPER_LIMIT) &&
+ (old_uv <= TEGRA_IO_PAD_1800000UV_UPPER_LIMIT)) ||
+ ((io_volt_uv > TEGRA_IO_PAD_1800000UV_UPPER_LIMIT) &&
+ (old_uv > TEGRA_IO_PAD_1800000UV_UPPER_LIMIT)))
+ break;
+
+ ret = tegra_io_pad_set_voltage(rinfo->pads_cfg->pad_id,
+ TEGRA_IO_PAD_1800000UV);
+ if (ret < 0) {
+ dev_err(rinfo->dev,
+ "Failed to set voltage %lu of pad %s: %d\n",
+ vdata->min_uV, rinfo->pads_cfg->name, ret);
+ return ret;
+ }
+ break;
+
+ case REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE:
+ io_volt_uv = (unsigned long)data;
+ io_volt = (io_volt_uv <= TEGRA_IO_PAD_1800000UV_UPPER_LIMIT) ?
+ TEGRA_IO_PAD_1800000UV : TEGRA_IO_PAD_3300000UV;
+ ret = tegra_io_pad_set_voltage(rinfo->pads_cfg->pad_id,
+ io_volt);
+ if (ret < 0) {
+ dev_err(rinfo->dev,
+ "Failed to set voltage %lu of pad %s: %d\n",
+ io_volt_uv, rinfo->pads_cfg->name, ret);
+ return ret;
+ }
+ break;
+
+ default:
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static int tegra_iop_pinctrl_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const struct platform_device_id *id = platform_get_device_id(pdev);
+ const struct tegra_io_pad_soc_data *soc_data;
+ struct device_node *np_parent = pdev->dev.parent->of_node;
+ struct tegra_io_pads_info *tiopi;
+ int ret, i;
+
+ if (!np_parent) {
+ dev_err(dev, "PMC should be register from DT\n");
+ return -ENODEV;
+ }
+
+ soc_data = (const struct tegra_io_pad_soc_data *)id->driver_data;
+
+ tiopi = devm_kzalloc(dev, sizeof(*tiopi), GFP_KERNEL);
+ if (!tiopi)
+ return -ENOMEM;
+
+ tiopi->rinfo = devm_kzalloc(dev, sizeof(*tiopi->rinfo) *
+ soc_data->num_pads_cfg, GFP_KERNEL);
+ if (!tiopi->rinfo)
+ return -ENOMEM;
+
+ tiopi->dev = &pdev->dev;
+ pdev->dev.of_node = np_parent;
+ tiopi->soc_data = soc_data;
+
+ for (i = 0; i < soc_data->num_pads_cfg; ++i) {
+ struct tegra_io_pads_regulator_info *rinfo = tiopi->rinfo + i;
+ const struct tegra_io_pads_cfg_info *pads_cfg =
+ &soc_data->pads_cfg[i];
+ struct regulator *regulator;
+ int io_volt_uv;
+ enum tegra_io_pad_voltage io_volt;
+
+ if (!pads_cfg->vsupply)
+ continue;
+
+ regulator = devm_regulator_get_optional(dev, pads_cfg->vsupply);
+ if (IS_ERR(regulator)) {
+ ret = PTR_ERR(regulator);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ continue;
+ }
+
+ io_volt_uv = regulator_get_voltage(regulator);
+ if (io_volt_uv < 0) {
+ dev_err(dev, "Failed to get voltage for rail %s: %d\n",
+ pads_cfg->vsupply, io_volt_uv);
+ return ret;
+ }
+
+ io_volt = (io_volt_uv <= TEGRA_IO_PAD_1800000UV_UPPER_LIMIT) ?
+ TEGRA_IO_PAD_1800000UV : TEGRA_IO_PAD_3300000UV;
+
+ ret = tegra_io_pad_set_voltage(pads_cfg->pad_id, io_volt);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set voltage %d of pad %s: %d\n",
+ io_volt_uv, pads_cfg->name, ret);
+ return ret;
+ }
+ rinfo->dev = tiopi->dev;
+ rinfo->regulator = regulator;
+ rinfo->pads_cfg = pads_cfg;
+
+ rinfo->regulator_nb.notifier_call =
+ tegra_io_pads_rail_change_notify_cb;
+ ret = devm_regulator_register_notifier(regulator,
+ &rinfo->regulator_nb);
+ if (ret < 0) {
+ dev_err(dev, "Failed to register regulator %s notifier: %d\n",
+ pads_cfg->name, ret);
+ return ret;
+ }
+ }
+
+ tegra_iop_pinctrl_desc.pins = tiopi->soc_data->pins_desc;
+ tegra_iop_pinctrl_desc.npins = tiopi->soc_data->num_pins_desc;
+ platform_set_drvdata(pdev, tiopi);
+
+ tiopi->pctl = devm_pinctrl_register(dev, &tegra_iop_pinctrl_desc,
+ tiopi);
+ if (IS_ERR(tiopi->pctl)) {
+ ret = PTR_ERR(tiopi->pctl);
+ dev_err(dev, "Failed to register io-pad pinctrl driver: %d\n",
+ ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+#define TEGRA124_PAD_INFO_TABLE(_entry_) \
+ _entry_(0, "audio", AUDIO, true, NULL), \
+ _entry_(1, "bb", BB, true, NULL), \
+ _entry_(2, "cam", CAM, true, NULL), \
+ _entry_(3, "comp", COMP, true, NULL), \
+ _entry_(4, "csia", CSIA, true, NULL), \
+ _entry_(5, "csib", CSIB, true, NULL), \
+ _entry_(6, "csie", CSIE, true, NULL), \
+ _entry_(7, "dsi", DSI, true, NULL), \
+ _entry_(8, "dsib", DSIB, true, NULL), \
+ _entry_(9, "dsic", DSIC, true, NULL), \
+ _entry_(10, "dsid", DSID, true, NULL), \
+ _entry_(11, "hdmi", HDMI, true, NULL), \
+ _entry_(12, "hsic", HSIC, true, NULL), \
+ _entry_(13, "hv", HV, true, NULL), \
+ _entry_(14, "lvds", LVDS, true, NULL), \
+ _entry_(15, "mipi-bias", MIPI_BIAS, true, NULL), \
+ _entry_(16, "nand", NAND, true, NULL), \
+ _entry_(17, "pex-bias", PEX_BIAS, true, NULL), \
+ _entry_(18, "pex-clk1", PEX_CLK1, true, NULL), \
+ _entry_(19, "pex-clk2", PEX_CLK2, true, NULL), \
+ _entry_(20, "pex-ctrl", PEX_CNTRL, true, NULL), \
+ _entry_(21, "sdmmc1", SDMMC1, true, NULL), \
+ _entry_(22, "sdmmc3", SDMMC3, true, NULL), \
+ _entry_(23, "sdmmc4", SDMMC4, true, NULL), \
+ _entry_(24, "sys-ddc", SYS_DDC, true, NULL), \
+ _entry_(25, "uart", UART, true, NULL), \
+ _entry_(26, "usb0", USB0, true, NULL), \
+ _entry_(27, "usb1", USB1, true, NULL), \
+ _entry_(28, "usb2", USB2, true, NULL), \
+ _entry_(29, "usb-bias", USB_BIAS, true, NULL)
+
+#define TEGRA210_PAD_INFO_TABLE(_entry_) \
+ _entry_(0, "audio", AUDIO, true, "vddio-audio"), \
+ _entry_(1, "audio-hv", AUDIO_HV, true, "vddio-audio-hv"), \
+ _entry_(2, "cam", CAM, true, "vddio-cam"), \
+ _entry_(3, "csia", CSIA, true, NULL), \
+ _entry_(4, "csib", CSIB, true, NULL), \
+ _entry_(5, "csic", CSIC, true, NULL), \
+ _entry_(6, "csid", CSID, true, NULL), \
+ _entry_(7, "csie", CSIE, true, NULL), \
+ _entry_(8, "csif", CSIF, true, NULL), \
+ _entry_(9, "dbg", DBG, true, "vddio-dbg"), \
+ _entry_(10, "debug-nonao", DEBUG_NONAO, true, NULL), \
+ _entry_(11, "dmic", DMIC, true, "vddio-dmic"), \
+ _entry_(12, "dp", DP, true, NULL), \
+ _entry_(13, "dsi", DSI, true, NULL), \
+ _entry_(14, "dsib", DSIB, true, NULL), \
+ _entry_(15, "dsic", DSIC, true, NULL), \
+ _entry_(16, "dsid", DSID, true, NULL), \
+ _entry_(17, "emmc", SDMMC4, true, NULL), \
+ _entry_(18, "emmc2", EMMC2, true, NULL), \
+ _entry_(19, "gpio", GPIO, true, "vddio-gpio"), \
+ _entry_(20, "hdmi", HDMI, true, NULL), \
+ _entry_(21, "hsic", HSIC, true, NULL), \
+ _entry_(22, "lvds", LVDS, true, NULL), \
+ _entry_(23, "mipi-bias", MIPI_BIAS, true, NULL), \
+ _entry_(24, "pex-bias", PEX_BIAS, true, NULL), \
+ _entry_(25, "pex-clk1", PEX_CLK1, true, NULL), \
+ _entry_(26, "pex-clk2", PEX_CLK2, true, NULL), \
+ _entry_(27, "pex-ctrl", PEX_CNTRL, false, "vddio-pex-ctrl"), \
+ _entry_(28, "sdmmc1", SDMMC1, true, "vddio-sdmmc1"), \
+ _entry_(29, "sdmmc3", SDMMC3, true, "vddio-sdmmc3"), \
+ _entry_(30, "spi", SPI, true, "vddio-spi"), \
+ _entry_(31, "spi-hv", SPI_HV, true, "vddio-spi-hv"), \
+ _entry_(32, "uart", UART, true, "vddio-uart"), \
+ _entry_(33, "usb0", USB0, true, NULL), \
+ _entry_(34, "usb1", USB1, true, NULL), \
+ _entry_(35, "usb2", USB2, true, NULL), \
+ _entry_(36, "usb3", USB3, true, NULL), \
+ _entry_(37, "usb-bias", USB_BIAS, true, NULL)
+
+#define TEGRA_IO_PAD_INFO(_id, _name, _pad_id, _lpstate, _vsupply) \
+ { \
+ .name = _name, \
+ .pins = {(_id)}, \
+ .pad_id = TEGRA_IO_PAD_##_pad_id, \
+ .vsupply = (_vsupply), \
+ .support_low_power_state = (_lpstate), \
+ }
+
+static const struct tegra_io_pads_cfg_info tegra124_io_pads_cfg_info[] = {
+ TEGRA124_PAD_INFO_TABLE(TEGRA_IO_PAD_INFO),
+};
+
+static const struct tegra_io_pads_cfg_info tegra210_io_pads_cfg_info[] = {
+ TEGRA210_PAD_INFO_TABLE(TEGRA_IO_PAD_INFO),
+};
+
+#define TEGRA_IO_PAD_DESC(_id, _name, _pad_id, _lpstate, _vsupply) \
+ PINCTRL_PIN(_id, _name)
+
+static const struct pinctrl_pin_desc tegra124_io_pads_pinctrl_desc[] = {
+ TEGRA124_PAD_INFO_TABLE(TEGRA_IO_PAD_DESC),
+};
+
+static const struct pinctrl_pin_desc tegra210_io_pads_pinctrl_desc[] = {
+ TEGRA210_PAD_INFO_TABLE(TEGRA_IO_PAD_DESC),
+};
+
+static const struct tegra_io_pad_soc_data tegra124_io_pad_soc_data = {
+ .pins_desc = tegra124_io_pads_pinctrl_desc,
+ .num_pins_desc = ARRAY_SIZE(tegra124_io_pads_pinctrl_desc),
+ .pads_cfg = tegra124_io_pads_cfg_info,
+ .num_pads_cfg = ARRAY_SIZE(tegra124_io_pads_cfg_info),
+};
+
+static const struct tegra_io_pad_soc_data tegra210_io_pad_soc_data = {
+ .pins_desc = tegra210_io_pads_pinctrl_desc,
+ .num_pins_desc = ARRAY_SIZE(tegra210_io_pads_pinctrl_desc),
+ .pads_cfg = tegra210_io_pads_cfg_info,
+ .num_pads_cfg = ARRAY_SIZE(tegra210_io_pads_cfg_info),
+};
+
+static const struct platform_device_id tegra_io_pads_dev_id[] = {
+ {
+ .name = "pinctrl-t124-io-pad",
+ .driver_data = (kernel_ulong_t)&tegra124_io_pad_soc_data,
+ }, {
+ .name = "pinctrl-t210-io-pad",
+ .driver_data = (kernel_ulong_t)&tegra210_io_pad_soc_data,
+ }, {
+ },
+};
+MODULE_DEVICE_TABLE(platform, tegra_io_pads_dev_id);
+
+static struct platform_driver tegra_iop_pinctrl_driver = {
+ .driver = {
+ .name = "pinctrl-tegra-io-pad",
+ },
+ .probe = tegra_iop_pinctrl_probe,
+ .id_table = tegra_io_pads_dev_id,
+};
+
+module_platform_driver(tegra_iop_pinctrl_driver);
+
+MODULE_DESCRIPTION("NVIDIA TEGRA IO pad Control Driver");
+MODULE_AUTHOR("Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 0/9] rockchip: add more power domain and devices dts for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai-TNX95d0MmH7DzftRWevZcw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
Caesar Wang, Arnd Bergmann, Frank Wang, Yakir Yang, zhangqing,
Rob Herring, Shawn Lin, Catalin Marinas, David Wu, Brian Norris,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Douglas Anderson,
Will Deacon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jianqun Xu,
Masahiro Yamada, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ziyuan Xu,
Mark
Hi all,
Please allow me to integrate these patches.
They are missing or losing for upstream, then there are some patches
are always depending on them.
The following patches are releated to PD.
git log --oneline
827198c arm64: dts: rockchip: add the usb3 pd for rk3399
95e95b4 arm64: dts: rockchip: support dwc3 USB for rk3399
3ced49c arm64: dts: rockchip: add pd_edp node for rk3399
e19db3f arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
eb92079 arm64: dts: rockchip: add backlight support for rk3399 evb board
20b8135 arm64: dts: rockchip: add eDP device node for rk3399
480a1bb arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
4964c0a arm64: dts: rockchip: add pd_sd power node for rk3399
c407a4c arm64: dts: rockchip: add eMMC's power domain support for rk3399
----
Hi Heiko & guys,
This series patches support the below PDs.
1) sd & emmc pd
4964c0a arm64: dts: rockchip: add pd_sd power node for rk3399
c407a4c arm64: dts: rockchip: add eMMC's power domain support for rk3399
2) edp pd
3ced49c arm64: dts: rockchip: add pd_edp node for rk3399
e19db3f arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
eb92079 arm64: dts: rockchip: add backlight support for rk3399 evb board
20b8135 arm64: dts: rockchip: add eDP device node for rk3399
480a1bb arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
3) usb3 pd
827198c arm64: dts: rockchip: add the usb3 pd for rk3399
95e95b4 arm64: dts: rockchip: support dwc3 USB for rk3399
Thanks,
Caesar
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/376558
- Verified on ChromeOS kernel4.4
- v1 on https://patchwork.kernel.org/patch/9322553/
- Reviewed-on: https://chromium-review.googlesource.com/386483
- Verified on ChromeOS kernel4.4
- Yakir posted the original patch on
- https://patchwork.kernel.org/patch/9191777
- the original patches from brian posting on
https://chromium-review.googlesource.com/343603
- Reviewed-on: https://chromium-review.googlesource.com/384280
Brian Norris (1):
arm64: dts: rockchip: support dwc3 USB for rk3399
Caesar Wang (1):
arm64: dts: rockchip: add the usb3 pd for rk3399
Mark Yao (1):
arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
Yakir Yang (3):
arm64: dts: rockchip: add eDP device node for rk3399
arm64: dts: rockchip: add backlight support for rk3399 evb board
arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
Ziyuan Xu (1):
arm64: dts: rockchip: add eMMC's power domain support for rk3399
zhangqing (2):
arm64: dts: rockchip: add pd_sd power node for rk3399
arm64: dts: rockchip: add pd_edp node for rk3399
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 40 ++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 210 ++++++++++++++++++++++++++++
2 files changed, 250 insertions(+)
--
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 v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai, tfiga, Ziyuan Xu, Elaine Zhang, Caesar Wang,
Douglas Anderson, David Wu, Jianqun Xu, Yakir Yang, Brian Norris,
linux-kernel, linux-rockchip, devicetree, Rob Herring,
Will Deacon, Mark Rutland, Catalin Marinas, linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Ziyuan Xu <xzy.xu@rock-chips.com>
Control power domain for eMMC via genpd to reduce power consumption.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/376558
- Verified on ChromeOS kernel4.4
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index cbb7f8b..b401176 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -269,6 +269,7 @@
#clock-cells = <0>;
phys = <&emmc_phy>;
phy-names = "phy_arasan";
+ power-domains = <&power RK3399_PD_EMMC>;
status = "disabled";
};
@@ -690,6 +691,11 @@
status = "disabled";
};
+ qos_emmc: qos@ffa58000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa58000 0x0 0x20>;
+ };
+
qos_gmac: qos@ffa5c000 {
compatible = "syscon";
reg = <0x0 0xffa5c000 0x0 0x20>;
@@ -823,6 +829,11 @@
};
/* These power domains are grouped by VD_LOGIC */
+ pd_emmc@RK3399_PD_EMMC {
+ reg = <RK3399_PD_EMMC>;
+ clocks = <&cru ACLK_EMMC>;
+ pm_qos = <&qos_emmc>;
+ };
pd_gmac@RK3399_PD_GMAC {
reg = <RK3399_PD_GMAC>;
clocks = <&cru ACLK_GMAC>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai-TNX95d0MmH7DzftRWevZcw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
zhangqing, Caesar Wang, Douglas Anderson, David Wu, Jianqun Xu,
Yakir Yang, Brian Norris, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Will Deacon,
Mark Rutland, Catalin Marinas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478697721-2323-1-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
From: zhangqing <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
1.add pd node for RK3399 Soc
2.create power domain tree
3.add qos node for domain
4.add the pd_sd consumers node
Signed-off-by: Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v2:
- v1 on https://patchwork.kernel.org/patch/9322553/
- Reviewed-on: https://chromium-review.googlesource.com/386483
- Verified on ChromeOS kernel4.4
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index b401176..e5b5b3d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -253,6 +253,7 @@
<&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
+ power-domains = <&power RK3399_PD_SD>;
status = "disabled";
};
@@ -691,6 +692,11 @@
status = "disabled";
};
+ qos_sd: qos@ffa74000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa74000 0x0 0x20>;
+ };
+
qos_emmc: qos@ffa58000 {
compatible = "syscon";
reg = <0x0 0xffa58000 0x0 0x20>;
@@ -839,6 +845,12 @@
clocks = <&cru ACLK_GMAC>;
pm_qos = <&qos_gmac>;
};
+ pd_sd@RK3399_PD_SD {
+ reg = <RK3399_PD_SD>;
+ clocks = <&cru HCLK_SDMMC>,
+ <&cru SCLK_SDMMC>;
+ pm_qos = <&qos_sd>;
+ };
pd_vio@RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
#address-cells = <1>;
--
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 related
* [PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
Catalin Marinas, Ziyuan Xu, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
David Wu, Will Deacon, Douglas Anderson,
tfiga-F7+t8E8rja9g9hUCZPvPmw,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
eddie.cai-TNX95d0MmH7DzftRWevZcw, zhangqing, Yakir Yang, Mark Yao,
Jianqun Xu, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Caesar Wang
In-Reply-To: <1478697721-2323-1-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
From: Mark Yao <mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Add the core display-subsystem node and the two display controllers
available on the rk3399.
Signed-off-by: Mark Yao <mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Yakir Yang <ykk-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58 ++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e5b5b3d..f1d289a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1290,6 +1290,64 @@
status = "disabled";
};
+ vopl: vop@ff8f0000 {
+ compatible = "rockchip,rk3399-vop-lit";
+ reg = <0x0 0xff8f0000 0x0 0x3efc>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vopl_mmu>;
+ status = "disabled";
+
+ vopl_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ vopl_mmu: iommu@ff8f3f00 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xff8f3f00 0x0 0x100>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "vopl_mmu";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
+ vopb: vop@ff900000 {
+ compatible = "rockchip,rk3399-vop-big";
+ reg = <0x0 0xff900000 0x0 0x3efc>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vopb_mmu>;
+ status = "disabled";
+
+ vopb_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ vopb_mmu: iommu@ff903f00 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xff903f00 0x0 0x100>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "vopb_mmu";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
+ display_subsystem: display-subsystem {
+ compatible = "rockchip,display-subsystem";
+ ports = <&vopl_out>, <&vopb_out>;
+ status = "disabled";
+ };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <&grf>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/9] arm64: dts: rockchip: add eDP device node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai-TNX95d0MmH7DzftRWevZcw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
Yakir Yang, Caesar Wang, Douglas Anderson, David Wu, Jianqun Xu,
devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, zhangqing,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Will Deacon, Mark Rutland, Catalin Marinas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Xing Zheng
In-Reply-To: <1478697721-2323-1-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
From: Yakir Yang <ykk-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Add rk3399 eDP device node, and connect to VOP device node with
remote endpoint.
Signed-off-by: Yakir Yang <ykk-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
(Caesar rebase the lastest and solve the conflict)
---
Changes in v2:
- Yakir posted the original patch on
- https://patchwork.kernel.org/patch/9191777
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 52 ++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index f1d289a..6544910 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1304,6 +1304,11 @@
vopl_out: port {
#address-cells = <1>;
#size-cells = <0>;
+
+ vopl_out_edp: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&edp_in_vopl>;
+ };
};
};
@@ -1330,6 +1335,11 @@
vopb_out: port {
#address-cells = <1>;
#size-cells = <0>;
+
+ vopb_out_edp: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&edp_in_vopb>;
+ };
};
};
@@ -1342,6 +1352,41 @@
status = "disabled";
};
+ edp: edp@ff970000 {
+ compatible = "rockchip,rk3399-edp";
+ reg = <0x0 0xff970000 0x0 0x8000>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ resets = <&cru SRST_P_EDP_CTRL>;
+ reset-names = "dp";
+ rockchip,grf = <&grf>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_hpd>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+
+ edp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+ };
+ };
+
display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";
ports = <&vopl_out>, <&vopb_out>;
@@ -1469,6 +1514,13 @@
};
};
+ edp {
+ edp_hpd: edp-hpd {
+ rockchip,pins =
+ <4 23 RK_FUNC_2 &pcfg_pull_none>;
+ };
+ };
+
gmac {
rgmii_pins: rgmii-pins {
rockchip,pins =
--
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 related
* [PATCH v2 5/9] arm64: dts: rockchip: add backlight support for rk3399 evb board
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai, tfiga, Yakir Yang, Caesar Wang, devicetree,
Arnd Bergmann, Jianqun Xu, Masahiro Yamada, linux-rockchip,
linux-kernel, Shawn Lin, Rob Herring, linux-arm-kernel,
Will Deacon, Frank Wang, Mark Rutland, Catalin Marinas,
Roger Chen
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Yakir Yang <ykk@rock-chips.com>
Add backlight node for evb board, perpare for panel device node.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 40 +++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
index 8e82497..c585e93 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -49,6 +49,46 @@
compatible = "rockchip,rk3399-evb", "rockchip,rk3399",
"google,rk3399evb-rev2";
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm0 0 25000 0>;
+ brightness-levels = <
+ 0 1 2 3 4 5 6 7
+ 8 9 10 11 12 13 14 15
+ 16 17 18 19 20 21 22 23
+ 24 25 26 27 28 29 30 31
+ 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47
+ 48 49 50 51 52 53 54 55
+ 56 57 58 59 60 61 62 63
+ 64 65 66 67 68 69 70 71
+ 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87
+ 88 89 90 91 92 93 94 95
+ 96 97 98 99 100 101 102 103
+ 104 105 106 107 108 109 110 111
+ 112 113 114 115 116 117 118 119
+ 120 121 122 123 124 125 126 127
+ 128 129 130 131 132 133 134 135
+ 136 137 138 139 140 141 142 143
+ 144 145 146 147 148 149 150 151
+ 152 153 154 155 156 157 158 159
+ 160 161 162 163 164 165 166 167
+ 168 169 170 171 172 173 174 175
+ 176 177 178 179 180 181 182 183
+ 184 185 186 187 188 189 190 191
+ 192 193 194 195 196 197 198 199
+ 200 201 202 203 204 205 206 207
+ 208 209 210 211 212 213 214 215
+ 216 217 218 219 220 221 222 223
+ 224 225 226 227 228 229 230 231
+ 232 233 234 235 236 237 238 239
+ 240 241 242 243 244 245 246 247
+ 248 249 250 251 252 253 254 255>;
+ default-brightness-level = <200>;
+ enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+ };
+
clkin_gmac: external-gmac-clock {
compatible = "fixed-clock";
clock-frequency = <125000000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 6/9] arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai, tfiga, Yakir Yang, Caesar Wang, Douglas Anderson,
David Wu, Jianqun Xu, devicetree, Brian Norris, linux-kernel,
zhangqing, Shawn Lin, Rob Herring, Will Deacon, linux-rockchip,
Mark Rutland, Catalin Marinas, linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Yakir Yang <ykk@rock-chips.com>
The pclk_vio_grf supply power for VIO GRF IOs, if it is disabled, driver
would failed to operate the VIO GRF registers.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 6544910..74deb44 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1356,8 +1356,8 @@
compatible = "rockchip,rk3399-edp";
reg = <0x0 0xff970000 0x0 0x8000>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>;
- clock-names = "dp", "pclk";
+ clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>, <&cru PCLK_VIO_GRF>;
+ clock-names = "dp", "pclk", "grf";
resets = <&cru SRST_P_EDP_CTRL>;
reset-names = "dp";
rockchip,grf = <&grf>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 7/9] arm64: dts: rockchip: add pd_edp node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai, tfiga, zhangqing, Caesar Wang, Douglas Anderson,
David Wu, Jianqun Xu, Yakir Yang, Brian Norris, linux-kernel,
linux-rockchip, devicetree, Rob Herring, Will Deacon,
Mark Rutland, Catalin Marinas, linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: zhangqing <zhangqing@rock-chips.com>
1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain
4. add the pd support for edp
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 74deb44..09ebf4e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -835,6 +835,10 @@
};
/* These power domains are grouped by VD_LOGIC */
+ pd_edp@RK3399_PD_EDP {
+ reg = <RK3399_PD_EDP>;
+ clocks = <&cru PCLK_EDP_CTRL>;
+ };
pd_emmc@RK3399_PD_EMMC {
reg = <RK3399_PD_EMMC>;
clocks = <&cru ACLK_EMMC>;
@@ -1364,6 +1368,7 @@
status = "disabled";
pinctrl-names = "default";
pinctrl-0 = <&edp_hpd>;
+ power-domains = <&power RK3399_PD_EDP>;
ports {
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 8/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Caesar Wang @ 2016-11-09 13:22 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai-TNX95d0MmH7DzftRWevZcw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
Brian Norris, Caesar Wang, Douglas Anderson, David Wu, Jianqun Xu,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, zhangqing, Shawn Lin,
Rob Herring, Will Deacon,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Catalin Marinas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478697721-2323-1-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
From: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Add the dwc3 usb needed node information for rk3399.
Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v2:
- the original patches from brian posting on
https://chromium-review.googlesource.com/343603
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 54 ++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 09ebf4e..3659c56 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -353,6 +353,60 @@
status = "disabled";
};
+ usbdrd3_0: usb@fe800000 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
+ <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_0: dwc3@fe800000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe800000 0x0 0x100000>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
+ dr_mode = "otg";
+ phys = <&tcphy0_usb3>;
+ phy-names = "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,xhci-slow-suspend-quirk;
+ status = "disabled";
+ };
+ };
+
+ usbdrd3_1: usb@fe900000 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
+ <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_1: dwc3@fe900000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe900000 0x0 0x100000>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
+ dr_mode = "host";
+ phys = <&tcphy1_usb3>;
+ phy-names = "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,xhci-slow-suspend-quirk;
+ status = "disabled";
+ };
+ };
+
gic: interrupt-controller@fee00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <4>;
--
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 related
* [PATCH v2 9/9] arm64: dts: rockchip: add the usb3 pd for rk3399
From: Caesar Wang @ 2016-11-09 13:22 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai, tfiga, Caesar Wang, Douglas Anderson, David Wu,
Jianqun Xu, devicetree, Brian Norris, linux-kernel, zhangqing,
linux-rockchip, Rob Herring, Will Deacon, Ziyuan Xu, Mark Rutland,
Catalin Marinas, linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain
4. add the pd support for usb3
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/384280
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 3659c56..7480fa7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -376,6 +376,7 @@
snps,dis_u2_susphy_quirk;
snps,dis-del-phy-power-chg-quirk;
snps,xhci-slow-suspend-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
status = "disabled";
};
};
@@ -403,6 +404,7 @@
snps,dis_u2_susphy_quirk;
snps,dis-del-phy-power-chg-quirk;
snps,xhci-slow-suspend-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
status = "disabled";
};
};
@@ -746,6 +748,16 @@
status = "disabled";
};
+ qos_usb_otg0: qos@ffa70000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa70000 0x0 0x20>;
+ };
+
+ qos_usb_otg1: qos@ffa70080 {
+ compatible = "syscon";
+ reg = <0x0 0xffa70080 0x0 0x20>;
+ };
+
qos_sd: qos@ffa74000 {
compatible = "syscon";
reg = <0x0 0xffa74000 0x0 0x20>;
@@ -909,6 +921,12 @@
<&cru SCLK_SDMMC>;
pm_qos = <&qos_sd>;
};
+ pd_usb3@RK3399_PD_USB3 {
+ reg = <RK3399_PD_USB3>;
+ clocks = <&cru ACLK_USB3>;
+ pm_qos = <&qos_usb_otg0>,
+ <&qos_usb_otg1>;
+ };
pd_vio@RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: sound: document axentia,tse850-pcm5142 bindings
From: Mark Brown @ 2016-11-09 13:25 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Liam Girdwood, Rob Herring, Mark Rutland,
Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree
In-Reply-To: <1478622057-12426-2-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
On Tue, Nov 08, 2016 at 05:20:56PM +0100, Peter Rosin wrote:
> The TSE-850 is an FM Transmitter Station Equipment, designed to generate
> baseband signals for FM, mainly the DARC subcarrier, but other signals
> are also possible.
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-09 13:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, Dirk Behme, Linux-Renesas,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Pankaj Dubey,
linux-samsung-soc@vger.kernel.org
In-Reply-To: <CAMuHMdV4HG0aOr4Qp_OZXU=3jLeOJ2QaMKp09a3v4489ABbRcA@mail.gmail.com>
Hi Arnd,
On Mon, Nov 7, 2016 at 10:35 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>> Some Renesas SoCs may exist in different revisions, providing slightly
>> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
>> (errate and quirks). This needs to be catered for by drivers and/or
>> platform code. The recently proposed soc_device_match() API seems like
>> a good fit to handle this.
>>
>> This patch series implements the core infrastructure to provide SoC and
>> revision information through the SoC bus for Renesas ARM SoCs. It
>> consists of 7 patches:
>> - Patches 1-4 provide soc_device_match(), with some related fixes,
>> - Patches 5-7 implement identification of Renesas SoCs and
>> registration with the SoC bus,
>>
>> Changes compared to v1:
>> - Add Acked-by,
>> - New patches:
>> - "[4/7] base: soc: Provide a dummy implementation of
>> soc_device_match()",
>> - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
>> - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
>> (more similar patches available, I'm not yet spamming you all
>> with them),
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>> - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
>> devices with other SoCs,
>> - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
>> M1A: not accessible from the ARM core?),
>> - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
>> for SoCs that provide a chip ID register,
>> - Build renesas-soc only if SOC_BUS is enabled,
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>> - Remove verification of product IDs; just print the ID instead,
>> - Don't register the SoC bus if the chip ID register is missing,
>> - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
>> both).
>>
>> Merge strategy:
>> - In theory, patches 1-4 should go through Greg's driver core tree.
>> But it's a hard dependency for all users.
>> If people agree, I can provide an immutable branch in my
>> renesas-drivers repository, to be merged by all interested parties.
>> So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
> Shall I create the immutable branch now?
Arnd: are you happy with the new patches and changes?
Thanks again!
>> - Patches 5-7 obviously have to go through Simon's Renesas tree (after
>> merging the soc_device_match() core), and arm-soc.
>>
>> Tested on (machine, soc_id, optional revision):
>> EMEV2 KZM9D Board, emev2
>> Genmai, r7s72100
>> APE6EVM, r8a73a4, ES1.0
>> armadillo 800 eva, r8a7740, ES2.0
>> bockw, r8a7778
>> marzen, r8a7779, ES1.0
>> Lager, r8a7790, ES1.0
>> Koelsch, r8a7791, ES1.0
>> Porter, r8a7791, ES3.0
>> Blanche, r8a7792, ES1.1
>> Gose, r8a7793, ES1.0
>> Alt, r8a7794, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
>> Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
>> KZM-A9-GT, sh73a0, ES2.0
>>
>> For your convenience, this series (incl. more DT updates to add device
>> nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
>> in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
>> repository at
>> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
>> Its first user is support for R-Car H3 ES2.0 in branch
>> topic/r8a7795-es2-v1-rebased2.
>>
>> Thanks for your comments!
>>
>> Arnd Bergmann (1):
>> base: soc: Introduce soc_device_match() interface
>>
>> Geert Uytterhoeven (6):
>> base: soc: Early register bus when needed
>> base: soc: Check for NULL SoC device attributes
>> base: soc: Provide a dummy implementation of soc_device_match()
>> ARM: shmobile: Document DT bindings for CCCR and PRR
>> arm64: dts: r8a7795: Add device node for PRR
>> soc: renesas: Identify SoC and register with the SoC bus
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: axentia: tse850: add ASoC driver for the Axentia TSE-850
From: Mark Brown @ 2016-11-09 13:38 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Liam Girdwood, Rob Herring, Mark Rutland,
Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree
In-Reply-To: <1478622057-12426-3-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 2753 bytes --]
On Tue, Nov 08, 2016 at 05:20:57PM +0100, Peter Rosin wrote:
> +++ b/sound/soc/axentia/Kconfig
> @@ -0,0 +1,10 @@
> +config SND_SOC_AXENTIA_TSE850_PCM5142
> + tristate "ASoC driver for the Axentia TSE-850"
> + depends on ARCH_AT91 && OF
> + select ATMEL_SSC
> + select SND_ATMEL_SOC
> + select SND_ATMEL_SOC_SSC_DMA
> + select SND_SOC_PCM512x_I2C
> + help
> + Say Y if you want to add support for the ASoC driver for the
> + Axentia TSE-850 with a PCM5142 codec.
This just looks like a normal machine driver for an Atmel system which
would usually go in the atemel directory - why is a new directory being
created?
> +static int tse850_get_mux2(struct snd_kcontrol *kctrl,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_dapm_context *dapm = snd_soc_dapm_kcontrol_dapm(kctrl);
> + struct snd_soc_card *card = dapm->card;
> + struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
> + int ret;
> +
> + ret = gpiod_get_value(tse850->loop2);
> + if (ret < 0)
> + return ret;
We can't reliably read the value of output GPIOs (though in practice the
majority do support it) so it'd be better practice to use a state
variable to remember what we set. I'd also expect this to use the
_cansleep() GPIO calls as it's not in a context where sleeping would be
a problem.
> +int tse850_get_ana(struct snd_kcontrol *kctrl,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_dapm_context *dapm = snd_soc_dapm_kcontrol_dapm(kctrl);
> + struct snd_soc_card *card = dapm->card;
> + struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
> + int ret;
> +
> + ret = regulator_get_voltage(tse850->ana);
> + if (ret < 0)
> + return ret;
> +
> + if (ret < 11000000)
> + ret = 11000000;
> + else if (ret > 20000000)
> + ret = 20000000;
This needs some comments...
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct device *dev = rtd->dev;
> + struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
> + int dir = substream->stream != SNDRV_PCM_STREAM_PLAYBACK;
> + int div_id = dir ? ATMEL_SSC_RCMR_PERIOD : ATMEL_SSC_TCMR_PERIOD;
> + int period = snd_soc_params_to_frame_size(params) / 2 - 1;
Please write the logic out as normal if statements for legibility. It's
a bit concerning that we even need this function, it looks like pretty
basic stuff that I'd expect the CPU DAI to just be doing - why can't
this be the default behaviour of the CPU DAI?
> +static int tse850_init(struct snd_soc_pcm_runtime *rtd)
> +{
> + struct snd_soc_dapm_context *dapm = &rtd->card->dapm;
> +
> + return snd_soc_dapm_add_routes(dapm, tse850_intercon,
> + ARRAY_SIZE(tse850_intercon));
Set this up in the card data structure rather than open coding the call,
you can register DAPM routes there too.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: One Thousand Gnomes @ 2016-11-09 13:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, zhichang.yuan, catalin.marinas, will.deacon,
robh+dt, bhelgaas, olof, linux-arm-kernel, lorenzo.pieralisi,
linux-kernel, linuxarm, devicetree, linux-pci, linux-serial,
minyard, benh, liviu.dudau, zourongrong, john.garry,
gabriele.paoloni, zhichang.yuan02, kantyzc, xuwei5, marc.zyngier
In-Reply-To: <2368890.jTbyGqYR0M@wuerfel>
> I think it is a relatively safe assumption that there is only one
> ISA bridge. A lot of old drivers hardcode PIO or memory addresses
It's not a safe assumption for x86 at least. There are a few systems with
multiple ISA busses particularly older laptops with a docking station.
> when talking to an ISA device, so having multiple instances is
> already problematic.
PCMCIA devices handle it themselves so are ok. I'm not clear how the dual
PIIX4 configuration used in the older IBM laptop docks actually worked so
I assume the transaction went out of both bridges and providing one of
them responded the other kept silent as you simply stuffed the card into
the dock and it worked.
Alan
^ permalink raw reply
* Re: [PATCH 2/2] regulator: rn5t618: add RC5T619 PMIC support
From: Mark Brown @ 2016-11-09 14:02 UTC (permalink / raw)
To: Pierre-Hugues Husson
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161105161925.14910-3-phh-8tEavu1zA38@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 263 bytes --]
On Sat, Nov 05, 2016 at 05:19:25PM +0100, Pierre-Hugues Husson wrote:
> Extend the driver to support Ricoh RC5T619.
> Support the additional regulators and slightly different voltage ranges.
Acked-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH 11/13] ARM: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
From: Heiko Stuebner @ 2016-11-09 14:05 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-rockchip, ulf.hansson, robh+dt, krzk,
shawn.lin
In-Reply-To: <20161103062135.10697-12-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:33 CET schrieb Jaehoon Chung:
> In drivers/mmc/core/host.c, there is "max-frequency" property.
> It should be same behavior. So use the "max-frequency" instead of
> "clock-freq-min-max".
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
looks good, my veyron-pinky and rk3036-kylin still seem to work and hopefully
I haven't missed any spelling errors in the properties :-), so applied to my
dts32 branch for 4.10
Thanks
Heiko
^ permalink raw reply
* [PATCH] of/irq: improve error message on irq discovery process failure
From: Guilherme G. Piccoli @ 2016-11-09 14:05 UTC (permalink / raw)
To: devicetree; +Cc: linuxppc-dev, linux-pci, frowand.list, robh+dt, gpiccoli
On PowerPC machines some PCI slots might not have Level-triggered
interrupts capability (also know as Level Signaled Interrupts - LSI),
leading of_irq_parse_pci() to complain by presenting error messages
on the kernel log - in this case, the properties "interrupt-map" and
"interrupt-map-mask" are not present on the device's node on device
tree.
This patch introduces a different message for this specific case,
and it also reduces the level of the message from error to warning.
Before this patch, when an adapter was plugged in a slot without Level
interrupts capabilities, we saw generic error messages like this:
[54.239] pci 002d:70:00.0: of_irq_parse_pci() failed with rc=-22
Now, with this applied, we see the following specific message:
[19.947] pci 0014:60:00.0: of_irq_parse_pci() gave up. The slot of this
device has no Level-triggered Interrupts capability.
No functional changes were introduced.
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
---
drivers/of/irq.c | 5 ++++-
drivers/of/of_pci_irq.c | 8 +++++++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 393fea8..1ad6882 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -275,7 +275,10 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
of_node_put(ipar);
of_node_put(newpar);
- return -EINVAL;
+ /* Positive non-zero return means no Level-triggered Interrupts
+ * capability was found.
+ */
+ return ENOENT;
}
EXPORT_SYMBOL_GPL(of_irq_parse_raw);
diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
index 2306313..9b6f387 100644
--- a/drivers/of/of_pci_irq.c
+++ b/drivers/of/of_pci_irq.c
@@ -89,8 +89,14 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq
laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
laddr[1] = laddr[2] = cpu_to_be32(0);
rc = of_irq_parse_raw(laddr, out_irq);
- if (rc)
+
+ if (rc < 0) {
goto err;
+ } else if (rc > 0) {
+ dev_warn(&pdev->dev,
+ "of_irq_parse_pci() gave up. The slot of this device has no Level-triggered Interrupts capability.\n");
+ return -rc;
+ }
return 0;
err:
dev_err(&pdev->dev, "of_irq_parse_pci() failed with rc=%d\n", rc);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 2/3] ipmi/bt-bmc: maintain a request expiry list
From: Cédric Le Goater @ 2016-11-09 14:30 UTC (permalink / raw)
To: minyard, openipmi-developer, Joel Stanley
Cc: devicetree, Rob Herring, Brendan Higgins, linux-arm-kernel,
Arnd Bergmann
In-Reply-To: <a7aea2a7-6cb4-655e-3c69-1a156945e27b@acm.org>
On 11/07/2016 08:04 PM, Corey Minyard wrote:
> On 11/02/2016 02:57 AM, Cédric Le Goater wrote:
>> Regarding the response expiration handling, the IPMI spec says :
>>
>> The BMC must not return a given response once the corresponding
>> Request-to-Response interval has passed. The BMC can ensure this
>> by maintaining its own internal list of outstanding requests through
>> the interface. The BMC could age and expire the entries in the list
>> by expiring the entries at an interval that is somewhat shorter than
>> the specified Request-to-Response interval....
>>
>> To handle such case, we maintain list of received requests using the
>> seq number of the BT message to identify them. The list is updated
>> each time a request is received and a response is sent. The expiration
>> of the reponses is handled at each updates but also with a timer.
>
> This looks correct, but it seems awfully complicated.
>
> Why can't you get the current time before the wait_event_interruptible()
> and then compare the time before you do the write? That would seem to
> accomplish the same thing without any lists or extra locks.
Well, the expiry list needs a request identifier and it is currently using
the Seq byte for this purpose. So the BT message needs to be read to grab
that byte. The request is added to a list and that involves some locking.
When the response is written, the first matching request is removed from
the list and a garbage collector loop is also run. Then, as we might not
get any responses to run that loop, we use a timer to empty the list from
any expired requests.
The read/write ops of the driver are protected with a mutex, the list and
the timer add their share of locking. That could have been done with RCU
surely but we don't really need performance in this driver.
Caveats :
bt_bmc_remove_request() should not be done in the writing loop though.
It needs a fix.
The request identifier is currently Seq but the spec say we should use
Seq, NetFn, and Command or an internal Seq value as a request identifier.
Google is also working on an OEM/Group extension (Brendan in CC: )
which has a different message format. I need to look closer at what
should be done in this case.
> Also, if you are going to have multiple writers on this interface, I don't
> think the interface will work correctly. I think you need to claim the
> mutex first. Otherwise you might get into a situation where two writers
> will wake up at the same time, the first writes and releases the mutex,
> then the second will find that the interface is busy and fail.
yes. that is a current problem in the driver and it is not really an
elegant way to handle concurrency. We are fine for the moment as we
only have one single threaded process using the device.
> If I am correct, the mutex will need to become interruptible and come
> first, I think. (And the timing would have to start before the mutex,
> of course.) This applies to both the read and write interface.
OK. I will look into fixing this problem first.
> Another thing is that this is request-to-release time. If a request takes
> a long time to process (say, a write to a flash device) the timeout would
> need to be decreased by the processing time.
Hmm, how would that fit with the "BT Interface Capabilities" which
defines :
BMC Request-to-Response time, in seconds, 1 based. 30 seconds, maximum.
This is a fixed value. And the spec only say :
The BMC could age and expire the entries in the list by expiring
the entries at an interval that is somewhat shorter than the
specified Request-to-Response interval.
May be I am misunderstanding.
> It's probably ok to not do that for the moment, but you may want to add
> a note. Fixing that would require adding a timeout for each message.
Thanks,
C.
> -corey
>
>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/char/ipmi/bt-bmc.c | 132 +++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 132 insertions(+)
>>
>> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
>> index fc9e8891eae3..e751e4a754b7 100644
>> --- a/drivers/char/ipmi/bt-bmc.c
>> +++ b/drivers/char/ipmi/bt-bmc.c
>> @@ -17,6 +17,7 @@
>> #include <linux/platform_device.h>
>> #include <linux/poll.h>
>> #include <linux/sched.h>
>> +#include <linux/slab.h>
>> #include <linux/timer.h>
>> /*
>> @@ -57,6 +58,15 @@
>> #define BT_BMC_BUFFER_SIZE 256
>> +#define BT_BMC_RESPONSE_TIME 5 /* seconds */
>> +
>> +struct ipmi_request {
>> + struct list_head list;
>> +
>> + u8 seq;
>> + unsigned long expires;
>> +};
>> +
>> struct bt_bmc {
>> struct device dev;
>> struct miscdevice miscdev;
>> @@ -65,6 +75,11 @@ struct bt_bmc {
>> wait_queue_head_t queue;
>> struct timer_list poll_timer;
>> struct mutex mutex;
>> +
>> + unsigned int response_time;
>> + struct timer_list requests_timer;
>> + spinlock_t requests_lock;
>> + struct list_head requests;
>> };
>> static atomic_t open_count = ATOMIC_INIT(0);
>> @@ -163,6 +178,94 @@ static int bt_bmc_open(struct inode *inode, struct file *file)
>> }
>> /*
>> + * lock should be held
>> + */
>> +static void drop_expired_requests(struct bt_bmc *bt_bmc)
>> +{
>> + unsigned long flags = 0;
>> + struct ipmi_request *req, *next;
>> + unsigned long next_expires = 0;
>> + int start_timer = 0;
>> +
>> + spin_lock_irqsave(&bt_bmc->requests_lock, flags);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + if (time_after_eq(jiffies, req->expires)) {
>> + pr_warn("BT: request seq:%d has expired. dropping\n",
>> + req->seq);
>> + list_del(&req->list);
>> + kfree(req);
>> + continue;
>> + }
>> + if (!start_timer) {
>> + start_timer = 1;
>> + next_expires = req->expires;
>> + } else {
>> + next_expires = min(next_expires, req->expires);
>> + }
>> + }
>> + spin_unlock_irqrestore(&bt_bmc->requests_lock, flags);
>> +
>> + /* and possibly restart */
>> + if (start_timer)
>> + mod_timer(&bt_bmc->requests_timer, next_expires);
>> +}
>> +
>> +static void requests_timer(unsigned long data)
>> +{
>> + struct bt_bmc *bt_bmc = (void *)data;
>> +
>> + drop_expired_requests(bt_bmc);
>> +}
>> +
>> +static int bt_bmc_add_request(struct bt_bmc *bt_bmc, u8 seq)
>> +{
>> + struct ipmi_request *req;
>> +
>> + req = kmalloc(sizeof(*req), GFP_KERNEL);
>> + if (!req)
>> + return -ENOMEM;
>> +
>> + req->seq = seq;
>> + req->expires = jiffies +
>> + msecs_to_jiffies(bt_bmc->response_time * 1000);
>> +
>> + spin_lock(&bt_bmc->requests_lock);
>> + list_add(&req->list, &bt_bmc->requests);
>> + spin_unlock(&bt_bmc->requests_lock);
>> +
>> + drop_expired_requests(bt_bmc);
>> + return 0;
>> +}
>> +
>> +static int bt_bmc_remove_request(struct bt_bmc *bt_bmc, u8 seq)
>> +{
>> + struct ipmi_request *req, *next;
>> + int ret = -EBADRQC; /* Invalid request code */
>> +
>> + spin_lock(&bt_bmc->requests_lock);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + /*
>> + * The sequence number should be unique, so remove the
>> + * first matching request found. If there are others,
>> + * they should expire
>> + */
>> + if (req->seq == seq) {
>> + list_del(&req->list);
>> + kfree(req);
>> + ret = 0;
>> + break;
>> + }
>> + }
>> + spin_unlock(&bt_bmc->requests_lock);
>> +
>> + if (ret)
>> + pr_warn("BT: request seq:%d is invalid\n", seq);
>> +
>> + drop_expired_requests(bt_bmc);
>> + return ret;
>> +}
>> +
>> +/*
>> * The BT (Block Transfer) interface means that entire messages are
>> * buffered by the host before a notification is sent to the BMC that
>> * there is data to be read. The first byte is the length and the
>> @@ -231,6 +334,13 @@ static ssize_t bt_bmc_read(struct file *file, char __user *buf,
>> len_byte = 0;
>> }
>> + if (ret > 0) {
>> + int ret2 = bt_bmc_add_request(bt_bmc, kbuffer[2]);
>> +
>> + if (ret2)
>> + ret = ret2;
>> + }
>> +
>> clr_b_busy(bt_bmc);
>> out_unlock:
>> @@ -283,12 +393,20 @@ static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
>> clr_wr_ptr(bt_bmc);
>> while (count) {
>> + int ret2;
>> +
>> nwritten = min_t(ssize_t, count, sizeof(kbuffer));
>> if (copy_from_user(&kbuffer, buf, nwritten)) {
>> ret = -EFAULT;
>> break;
>> }
>> + ret2 = bt_bmc_remove_request(bt_bmc, kbuffer[2]);
>> + if (ret2) {
>> + ret = ret2;
>> + break;
>> + }
>> +
>> bt_writen(bt_bmc, kbuffer, nwritten);
>> count -= nwritten;
>> @@ -438,6 +556,8 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> mutex_init(&bt_bmc->mutex);
>> init_waitqueue_head(&bt_bmc->queue);
>> + INIT_LIST_HEAD(&bt_bmc->requests);
>> + spin_lock_init(&bt_bmc->requests_lock);
>> bt_bmc->miscdev.minor = MISC_DYNAMIC_MINOR,
>> bt_bmc->miscdev.name = DEVICE_NAME,
>> @@ -451,6 +571,8 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> bt_bmc_config_irq(bt_bmc, pdev);
>> + bt_bmc->response_time = BT_BMC_RESPONSE_TIME;
>> +
>> if (bt_bmc->irq) {
>> dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
>> } else {
>> @@ -468,6 +590,9 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> BT_CR0_ENABLE_IBT,
>> bt_bmc->base + BT_CR0);
>> + setup_timer(&bt_bmc->requests_timer, requests_timer,
>> + (unsigned long)bt_bmc);
>> +
>> clr_b_busy(bt_bmc);
>> return 0;
>> @@ -476,10 +601,17 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> static int bt_bmc_remove(struct platform_device *pdev)
>> {
>> struct bt_bmc *bt_bmc = dev_get_drvdata(&pdev->dev);
>> + struct ipmi_request *req, *next;
>> misc_deregister(&bt_bmc->miscdev);
>> if (!bt_bmc->irq)
>> del_timer_sync(&bt_bmc->poll_timer);
>> +
>> + del_timer_sync(&bt_bmc->requests_timer);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + list_del(&req->list);
>> + kfree(req);
>> + }
>> return 0;
>> }
>>
>
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: mdio-mux: Add documentation for mdio mux for NSP SoC
From: Andrew Lunn @ 2016-11-09 14:34 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy
Cc: Rob Herring, Mark Rutland, Russell King, Ray Jui, Scott Branden,
Jon Mason, Florian Fainelli, Kishon Vijay Abraham I,
bcm-kernel-feedback-list, netdev, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1478683994-12008-2-git-send-email-yendapally.reddy@broadcom.com>
On Wed, Nov 09, 2016 at 04:33:09AM -0500, Yendapally Reddy Dhananjaya Reddy wrote:
> Add documentation for mdio mux available in Broadcom NSP SoC
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
> ---
> .../devicetree/bindings/net/brcm,mdio-mux-nsp.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
>
> diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt b/Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
> new file mode 100644
> index 0000000..b749a2b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
> @@ -0,0 +1,57 @@
> +Properties for an MDIO bus multiplexer available in Broadcom NSP SoC.
> +
> +This MDIO bus multiplexer defines buses that could access the internal
> +phys as well as external to SoCs. When child bus is selected, one needs
Hi Yendapally
Since we are in the networking subsystem, when we see phy, we think
Ethernet PHY. But broadcom mdio mux is generic and can have any sort
of PHY or device connected to it. To avoid confusion and
missunderstanding, please could you try to prefix each 'PHY' in the
with an indication of what type it is, 'Ethernet PHY', 'USB phy',
'SERDES PHY', or 'generic PHY/mdio device'.
And i mean this in general, not just this patch.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH 12/13] ARM64: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
From: Heiko Stuebner @ 2016-11-09 14:37 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-rockchip, ulf.hansson, robh+dt, krzk,
shawn.lin
In-Reply-To: <20161103062135.10697-13-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:34 CET schrieb Jaehoon Chung:
> In drivers/mmc/core/host.c, there is "max-freqeuncy" property.
> It should be same behavior, So Use the "max-frequency" instead of
> "clock-freq-min-max".
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
applied to my dts64 branch for 4.10
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH 3/3] ipmi/bt-bmc: add a sysfs file to configure a maximum response time
From: Cédric Le Goater @ 2016-11-09 14:42 UTC (permalink / raw)
To: minyard, openipmi-developer, Joel Stanley
Cc: devicetree, Rob Herring, linux-arm-kernel, Arnd Bergmann
In-Reply-To: <3a1f8e6d-c935-3404-ffa0-81b19d170731@acm.org>
On 11/07/2016 07:37 PM, Corey Minyard wrote:
> Sorry, I was at Plumbers and extra busy with other stuff. Just getting around to reviewing this.
>
> On 11/02/2016 02:57 AM, Cédric Le Goater wrote:
>> We could also use an ioctl for that purpose. sysfs seems a better
>> approach.
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/char/ipmi/bt-bmc.c | 31 +++++++++++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
>> index e751e4a754b7..d7146f0e900e 100644
>> --- a/drivers/char/ipmi/bt-bmc.c
>> +++ b/drivers/char/ipmi/bt-bmc.c
>> @@ -84,6 +84,33 @@ struct bt_bmc {
>> static atomic_t open_count = ATOMIC_INIT(0);
>> +static ssize_t bt_bmc_show_response_time(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct bt_bmc *bt_bmc = dev_get_drvdata(dev);
>> +
>> + return snprintf(buf, PAGE_SIZE - 1, "%d\n", bt_bmc->response_time);
>> +}
>> +
>> +static ssize_t bt_bmc_set_response_time(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct bt_bmc *bt_bmc = dev_get_drvdata(dev);
>> + unsigned long val;
>> + int err;
>> +
>> + err = kstrtoul(buf, 0, &val);
>> + if (err)
>> + return err;
>> + bt_bmc->response_time = val;
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR(response_time, 0644,
>> + bt_bmc_show_response_time, bt_bmc_set_response_time);
>> +
>> static u8 bt_inb(struct bt_bmc *bt_bmc, int reg)
>> {
>> return ioread8(bt_bmc->base + reg);
>> @@ -572,6 +599,10 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> bt_bmc_config_irq(bt_bmc, pdev);
>> bt_bmc->response_time = BT_BMC_RESPONSE_TIME;
>> + rc = device_create_file(&pdev->dev, &dev_attr_response_time);
>> + if (rc)
>> + dev_warn(&pdev->dev, "can't create response_time file\n");
>> +
>
> You added an extra space here.
yes. I will remove it in the next version.
The patch raises a few questions on the "BT Interface Capabilities" :
- should we use sysfs or a specific ioctl to configure the driver ?
- should the driver handle directly the response to the "Get BT
Interface Capabilities" command ?
What is your opinion ?
Thanks,
C.
>> if (bt_bmc->irq) {
>> dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] soc: qcom: Add SoC info driver
From: Geert Uytterhoeven @ 2016-11-09 14:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Arnd Bergmann, Imran Khan, Andy Gross, David Brown, Rob Herring,
Mark Rutland, open list:ARM/QUALCOMM SUPPORT,
open list:ARM/QUALCOMM SUPPORT,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Geert Uytterhoeven
In-Reply-To: <20161102162811.GN25787@tuxbot>
Hi Bjorn,
On Wed, Nov 2, 2016 at 5:28 PM, Bjorn Andersson
<bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Wed 26 Oct 07:05 PDT 2016, Arnd Bergmann wrote:
>> On Wednesday, October 26, 2016 7:20:42 PM CEST Imran Khan wrote:
>> > On 10/26/2016 2:19 AM, Arnd Bergmann wrote:
>> > > On Tuesday, October 25, 2016 3:23:34 PM CEST Imran Khan wrote:
>> > >> On 10/21/2016 4:03 PM, Arnd Bergmann wrote:
>> > >> Okay. I will go for human readable IDs. Can we add 2 more fields
>> > >> in the generic structure.
>> > >> These 2 fields would be:
>> > >>
>> > >> vendor: A string for vendor name
>> > >> serial_number: A string containing serial number for the platform
>> > >
>> > >
>> > > serial_number seems straightforward, adding this seems like a good
>> > > idea. I don't understand yet what would go into the vendor field
>> > > though. For this particular driver, is it always "Qualcomm", or
>> > > would it be a third-party that makes a device based on that chip?
>> >
>> > As we are talking about generic soc_device_attribute fields, I was hoping that
>> > having a vendor field would be helpful as along with family it would provide
>> > a more thorough information. Also as more than one foundries may be used for
>> > a soc, can we have a field say foundry_id to provide this information.
>>
>> My first feeling is that this 'vendor' information can should be
>> derived from the family.
>
> In [1] Geert just put the vendor directly into "family", while Imran
> uses "Snapdragon" (which I find reasonable in the Qualcomm case). But it
> seems like Geert would like a "vendor" as well, rather than a "family".
>
> And if "family" really is supposed to contain the "SoC family name" and
> we're trying to provide user space with some useful information (for
> some reason), should we just rely on the unlikeliness of two vendors
> using the same family name?
>
> [1] http://www.mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1261742.html
I think vendor is slightly less volatile than family. Family may
change overnight
if marketing had a good dream. Well, vendor may change, too...
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
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