* Applied "ASoC: pcm186x: Add PCM186x binding documentation" to the asoc tree
From: Mark Brown @ 2017-12-06 13:07 UTC (permalink / raw)
Cc: Mark Rutland, Rob Herring, alsa-devel, devicetree, Liam Girdwood,
Rob Herring, linux-kernel, Mark Brown, Andrew F . Davis
In-Reply-To: <20171129185015.5304-1-afd@ti.com>
The patch
ASoC: pcm186x: Add PCM186x binding documentation
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From eb2a8168b9fd69f66199d9d7e86d23fecfab4e33 Mon Sep 17 00:00:00 2001
From: "Andrew F. Davis" <afd@ti.com>
Date: Tue, 5 Dec 2017 14:52:55 -0600
Subject: [PATCH] ASoC: pcm186x: Add PCM186x binding documentation
Add the dt-binding documentation for the TI PCM186x 2ch and 4ch Audio
ADCs With Universal Front End.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/pcm186x.txt | 42 ++++++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/pcm186x.txt
diff --git a/Documentation/devicetree/bindings/sound/pcm186x.txt b/Documentation/devicetree/bindings/sound/pcm186x.txt
new file mode 100644
index 000000000000..1087f4855980
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/pcm186x.txt
@@ -0,0 +1,42 @@
+Texas Instruments PCM186x Universal Audio ADC
+
+These devices support both I2C and SPI (configured with pin strapping
+on the board).
+
+Required properties:
+
+ - compatible : "ti,pcm1862",
+ "ti,pcm1863",
+ "ti,pcm1864",
+ "ti,pcm1865"
+
+ - reg : The I2C address of the device for I2C, the chip select
+ number for SPI.
+
+ - avdd-supply: Analog core power supply (3.3v)
+ - dvdd-supply: Digital core power supply
+ - iovdd-supply: Digital IO power supply
+ See regulator/regulator.txt for more information
+
+CODEC input pins:
+ * VINL1
+ * VINR1
+ * VINL2
+ * VINR2
+ * VINL3
+ * VINR3
+ * VINL4
+ * VINR4
+
+The pins can be used in referring sound node's audio-routing property.
+
+Example:
+
+ pcm186x: audio-codec@4a {
+ compatible = "ti,pcm1865";
+ reg = <0x4a>;
+
+ avdd-supply = <®_3v3_analog>;
+ dvdd-supply = <®_3v3>;
+ iovdd-supply = <®_1v8>;
+ };
--
2.15.0
^ permalink raw reply related
* Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver
From: Mark Brown @ 2017-12-06 12:58 UTC (permalink / raw)
To: Katsuhiro Suzuki
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
Yamada, Masahiro/山田 真弘,
Masami Hiramatsu, Jassi Brar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <004801d36e57$ea1940d0$be4bc270$@socionext.com>
[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]
On Wed, Dec 06, 2017 at 03:03:18PM +0900, Katsuhiro Suzuki wrote:
> > I'd expect this code to be structured more like a library - have a
> > driver that handles the specific IPs then have it call into a shared
> > block of code that does the generic bits. Though in this case the
> > device specific bit looks like a couple of tiny data tables so I'm not
> > sure it's worth making it conditional or separate at all.
> Sorry... I agree your opinion, but I can't imagine the detail.
> I think my driver has structure as follows (ex. startup):
> DAI: uniphier_aio_startup()@aio-core.c
> Lib: uniphier_aio_init()@aio-regctrl.c
> SoC specific: uniphier_aio_ld11_spec@aio-ld11.c
> Am I wrong? Would you mean split the functions in aio-regctl.[ch] to other
> kernel module? I wonder if you could tell me the example from existing
> drivers. I'll try to fix my driver like as it.
One example is how all the drivers that use the generic dmaengine code
instantiate their DMA drivers, or how all the drivers for CODECs that
have both I2C and SPIi control interfaces instantiate - given that the
device specific code here seems to be mostly data tables that's probably
the closest thing.
> > At least. I do think we need to get to the bottom of how flexible the
> > hardware is first though.
> Yes, indeed. This hardware is more flexible and complex, but now I (and our
> company) don't use it. Of course, I don't want to hide some features of this
> hardware from ALSA people. I should try to upstream all features in the future,
> I think.
My main concern here is to make sure that when you decide you need to
use the more complex hardware that this can be done without too much
pain to existing machines (and that they can benefit from as much of the
enhanced functionality as is possible).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Applied "ASoC: tas6424: add bindings for TAS6424" to the asoc tree
From: Mark Brown @ 2017-12-06 12:58 UTC (permalink / raw)
To: Michael Stecklein
Cc: Mark Rutland, devicetree, alsa-devel, linux-kernel, Liam Girdwood,
Rob Herring, Andrew F . Davis, Mark Brown
In-Reply-To: <20171205155412.20137-2-afd@ti.com>
The patch
ASoC: tas6424: add bindings for TAS6424
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 2e662342962863bb6044ad581d7cc03795da4e9d Mon Sep 17 00:00:00 2001
From: Michael Stecklein <m-stecklein@ti.com>
Date: Tue, 5 Dec 2017 09:54:11 -0600
Subject: [PATCH] ASoC: tas6424: add bindings for TAS6424
Add the bindings for the TAS6424 digital amplifier.
Signed-off-by: Michael Stecklein <m-stecklein@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/ti,tas6424.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/ti,tas6424.txt
diff --git a/Documentation/devicetree/bindings/sound/ti,tas6424.txt b/Documentation/devicetree/bindings/sound/ti,tas6424.txt
new file mode 100644
index 000000000000..1c4ada0eef4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tas6424.txt
@@ -0,0 +1,20 @@
+Texas Instruments TAS6424 Quad-Channel Audio amplifier
+
+The TAS6424 serial control bus communicates through I2C protocols.
+
+Required properties:
+ - compatible: "ti,tas6424" - TAS6424
+ - reg: I2C slave address
+ - sound-dai-cells: must be equal to 0
+
+Example:
+
+tas6424: tas6424@6a {
+ compatible = "ti,tas6424";
+ reg = <0x6a>;
+
+ #sound-dai-cells = <0>;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/TAS6424-Q1
--
2.15.0
^ permalink raw reply related
* Applied "ASoC: tas6424: Add support for TAS6424 digital amplifier" to the asoc tree
From: Mark Brown @ 2017-12-06 12:58 UTC (permalink / raw)
To: Andreas Dannenberg
Cc: Mark Rutland, devicetree, alsa-devel, linux-kernel, Liam Girdwood,
Rob Herring, Andrew F . Davis, Mark Brown, Michael Stecklein
In-Reply-To: <20171205155412.20137-3-afd@ti.com>
The patch
ASoC: tas6424: Add support for TAS6424 digital amplifier
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 157b68babe3281222e08c9c58456ca22544f06bc Mon Sep 17 00:00:00 2001
From: Andreas Dannenberg <dannenberg@ti.com>
Date: Tue, 5 Dec 2017 09:54:12 -0600
Subject: [PATCH] ASoC: tas6424: Add support for TAS6424 digital amplifier
The Texas Instruments TAS6424 device is a high-efficiency quad-channel
Class-D audio power amplifier. Its digital time division multiplexed
(TDM) interface enables up to 2 devices to share the same bus,
supporting a total of eight channels from one audio serial port.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Michael Stecklein <m-stecklein@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/codecs/Kconfig | 8 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/tas6424.c | 707 +++++++++++++++++++++++++++++++++++++++++++++
sound/soc/codecs/tas6424.h | 144 +++++++++
4 files changed, 861 insertions(+)
create mode 100644 sound/soc/codecs/tas6424.c
create mode 100644 sound/soc/codecs/tas6424.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index a42ddbc93f3d..6c2e0d5426f7 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -148,6 +148,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TAS5086 if I2C
select SND_SOC_TAS571X if I2C
select SND_SOC_TAS5720 if I2C
+ select SND_SOC_TAS6424 if I2C
select SND_SOC_TFA9879 if I2C
select SND_SOC_TLV320AIC23_I2C if I2C
select SND_SOC_TLV320AIC23_SPI if SPI_MASTER
@@ -883,6 +884,13 @@ config SND_SOC_TAS5720
Enable support for Texas Instruments TAS5720L/M high-efficiency mono
Class-D audio power amplifiers.
+config SND_SOC_TAS6424
+ tristate "Texas Instruments TAS6424 Quad-Channel Audio amplifier"
+ depends on I2C
+ help
+ Enable support for Texas Instruments TAS6424 high-efficiency
+ digital input quad-channel Class-D audio power amplifiers.
+
config SND_SOC_TFA9879
tristate "NXP Semiconductors TFA9879 amplifier"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 0001069ce2a7..154abd758c30 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -156,6 +156,7 @@ snd-soc-sti-sas-objs := sti-sas.o
snd-soc-tas5086-objs := tas5086.o
snd-soc-tas571x-objs := tas571x.o
snd-soc-tas5720-objs := tas5720.o
+snd-soc-tas6424-objs := tas6424.o
snd-soc-tfa9879-objs := tfa9879.o
snd-soc-tlv320aic23-objs := tlv320aic23.o
snd-soc-tlv320aic23-i2c-objs := tlv320aic23-i2c.o
@@ -395,6 +396,7 @@ obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
obj-$(CONFIG_SND_SOC_TAS5086) += snd-soc-tas5086.o
obj-$(CONFIG_SND_SOC_TAS571X) += snd-soc-tas571x.o
obj-$(CONFIG_SND_SOC_TAS5720) += snd-soc-tas5720.o
+obj-$(CONFIG_SND_SOC_TAS6424) += snd-soc-tas6424.o
obj-$(CONFIG_SND_SOC_TFA9879) += snd-soc-tfa9879.o
obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o
obj-$(CONFIG_SND_SOC_TLV320AIC23_I2C) += snd-soc-tlv320aic23-i2c.o
diff --git a/sound/soc/codecs/tas6424.c b/sound/soc/codecs/tas6424.c
new file mode 100644
index 000000000000..49b87f6e85bf
--- /dev/null
+++ b/sound/soc/codecs/tas6424.c
@@ -0,0 +1,707 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ALSA SoC Texas Instruments TAS6424 Quad-Channel Audio Amplifier
+ *
+ * Copyright (C) 2016-2017 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Andreas Dannenberg <dannenberg@ti.com>
+ * Andrew F. Davis <afd@ti.com>
+ */
+
+#include <linux/module.h>
+#include <linux/errno.h>
+#include <linux/device.h>
+#include <linux/i2c.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/regulator/consumer.h>
+#include <linux/delay.h>
+
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+#include <sound/soc-dapm.h>
+#include <sound/tlv.h>
+
+#include "tas6424.h"
+
+/* Define how often to check (and clear) the fault status register (in ms) */
+#define TAS6424_FAULT_CHECK_INTERVAL 200
+
+static const char * const tas6424_supply_names[] = {
+ "dvdd", /* Digital power supply. Connect to 3.3-V supply. */
+ "vbat", /* Supply used for higher voltage analog circuits. */
+ "pvdd", /* Class-D amp output FETs supply. */
+};
+#define TAS6424_NUM_SUPPLIES ARRAY_SIZE(tas6424_supply_names)
+
+struct tas6424_data {
+ struct device *dev;
+ struct regmap *regmap;
+ struct regulator_bulk_data supplies[TAS6424_NUM_SUPPLIES];
+ struct delayed_work fault_check_work;
+ unsigned int last_fault1;
+ unsigned int last_fault2;
+ unsigned int last_warn;
+};
+
+/*
+ * DAC digital volumes. From -103.5 to 24 dB in 0.5 dB steps. Note that
+ * setting the gain below -100 dB (register value <0x7) is effectively a MUTE
+ * as per device datasheet.
+ */
+static DECLARE_TLV_DB_SCALE(dac_tlv, -10350, 50, 0);
+
+static const struct snd_kcontrol_new tas6424_snd_controls[] = {
+ SOC_SINGLE_TLV("Speaker Driver CH1 Playback Volume",
+ TAS6424_CH1_VOL_CTRL, 0, 0xff, 0, dac_tlv),
+ SOC_SINGLE_TLV("Speaker Driver CH2 Playback Volume",
+ TAS6424_CH2_VOL_CTRL, 0, 0xff, 0, dac_tlv),
+ SOC_SINGLE_TLV("Speaker Driver CH3 Playback Volume",
+ TAS6424_CH3_VOL_CTRL, 0, 0xff, 0, dac_tlv),
+ SOC_SINGLE_TLV("Speaker Driver CH4 Playback Volume",
+ TAS6424_CH4_VOL_CTRL, 0, 0xff, 0, dac_tlv),
+};
+
+static int tas6424_dac_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol, int event)
+{
+ struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
+ struct tas6424_data *tas6424 = snd_soc_codec_get_drvdata(codec);
+
+ dev_dbg(codec->dev, "%s() event=0x%0x\n", __func__, event);
+
+ if (event & SND_SOC_DAPM_POST_PMU) {
+ /* Observe codec shutdown-to-active time */
+ msleep(12);
+
+ /* Turn on TAS6424 periodic fault checking/handling */
+ tas6424->last_fault1 = 0;
+ tas6424->last_fault2 = 0;
+ tas6424->last_warn = 0;
+ schedule_delayed_work(&tas6424->fault_check_work,
+ msecs_to_jiffies(TAS6424_FAULT_CHECK_INTERVAL));
+ } else if (event & SND_SOC_DAPM_PRE_PMD) {
+ /* Disable TAS6424 periodic fault checking/handling */
+ cancel_delayed_work_sync(&tas6424->fault_check_work);
+ }
+
+ return 0;
+}
+
+static const struct snd_soc_dapm_widget tas6424_dapm_widgets[] = {
+ SND_SOC_DAPM_AIF_IN("DAC IN", "Playback", 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_DAC_E("DAC", NULL, SND_SOC_NOPM, 0, 0, tas6424_dac_event,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD),
+ SND_SOC_DAPM_OUTPUT("OUT")
+};
+
+static const struct snd_soc_dapm_route tas6424_audio_map[] = {
+ { "DAC", NULL, "DAC IN" },
+ { "OUT", NULL, "DAC" },
+};
+
+static int tas6424_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_codec *codec = dai->codec;
+ unsigned int rate = params_rate(params);
+ unsigned int width = params_width(params);
+ u8 sap_ctrl = 0;
+
+ dev_dbg(codec->dev, "%s() rate=%u width=%u\n", __func__, rate, width);
+
+ switch (rate) {
+ case 44100:
+ sap_ctrl |= TAS6424_SAP_RATE_44100;
+ break;
+ case 48000:
+ sap_ctrl |= TAS6424_SAP_RATE_48000;
+ break;
+ case 96000:
+ sap_ctrl |= TAS6424_SAP_RATE_96000;
+ break;
+ default:
+ dev_err(codec->dev, "unsupported sample rate: %u\n", rate);
+ return -EINVAL;
+ }
+
+ switch (width) {
+ case 16:
+ sap_ctrl |= TAS6424_SAP_TDM_SLOT_SZ_16;
+ break;
+ case 24:
+ break;
+ default:
+ dev_err(codec->dev, "unsupported sample width: %u\n", width);
+ return -EINVAL;
+ }
+
+ snd_soc_update_bits(codec, TAS6424_SAP_CTRL,
+ TAS6424_SAP_RATE_MASK |
+ TAS6424_SAP_TDM_SLOT_SZ_16,
+ sap_ctrl);
+
+ return 0;
+}
+
+static int tas6424_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt)
+{
+ struct snd_soc_codec *codec = dai->codec;
+ u8 serial_format = 0;
+
+ dev_dbg(codec->dev, "%s() fmt=0x%0x\n", __func__, fmt);
+
+ /* clock masters */
+ switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBS_CFS:
+ break;
+ default:
+ dev_err(codec->dev, "Invalid DAI master/slave interface\n");
+ return -EINVAL;
+ }
+
+ /* signal polarity */
+ switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+ case SND_SOC_DAIFMT_NB_NF:
+ break;
+ default:
+ dev_err(codec->dev, "Invalid DAI clock signal polarity\n");
+ return -EINVAL;
+ }
+
+ /* interface format */
+ switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_I2S:
+ serial_format |= TAS6424_SAP_I2S;
+ break;
+ case SND_SOC_DAIFMT_DSP_A:
+ serial_format |= TAS6424_SAP_DSP;
+ break;
+ case SND_SOC_DAIFMT_DSP_B:
+ /*
+ * We can use the fact that the TAS6424 does not care about the
+ * LRCLK duty cycle during TDM to receive DSP_B formatted data
+ * in LEFTJ mode (no delaying of the 1st data bit).
+ */
+ serial_format |= TAS6424_SAP_LEFTJ;
+ break;
+ case SND_SOC_DAIFMT_LEFT_J:
+ serial_format |= TAS6424_SAP_LEFTJ;
+ break;
+ default:
+ dev_err(codec->dev, "Invalid DAI interface format\n");
+ return -EINVAL;
+ }
+
+ snd_soc_update_bits(codec, TAS6424_SAP_CTRL,
+ TAS6424_SAP_FMT_MASK, serial_format);
+
+ return 0;
+}
+
+static int tas6424_set_dai_tdm_slot(struct snd_soc_dai *dai,
+ unsigned int tx_mask, unsigned int rx_mask,
+ int slots, int slot_width)
+{
+ struct snd_soc_codec *codec = dai->codec;
+ unsigned int first_slot, last_slot;
+ bool sap_tdm_slot_last;
+
+ dev_dbg(codec->dev, "%s() tx_mask=%d rx_mask=%d\n", __func__,
+ tx_mask, rx_mask);
+
+ if (!tx_mask || !rx_mask)
+ return 0; /* nothing needed to disable TDM mode */
+
+ /*
+ * Determine the first slot and last slot that is being requested so
+ * we'll be able to more easily enforce certain constraints as the
+ * TAS6424's TDM interface is not fully configurable.
+ */
+ first_slot = __ffs(tx_mask);
+ last_slot = __fls(rx_mask);
+
+ if (last_slot - first_slot != 4) {
+ dev_err(codec->dev, "tdm mask must cover 4 contiguous slots\n");
+ return -EINVAL;
+ }
+
+ switch (first_slot) {
+ case 0:
+ sap_tdm_slot_last = false;
+ break;
+ case 4:
+ sap_tdm_slot_last = true;
+ break;
+ default:
+ dev_err(codec->dev, "tdm mask must start at slot 0 or 4\n");
+ return -EINVAL;
+ }
+
+ snd_soc_update_bits(codec, TAS6424_SAP_CTRL, TAS6424_SAP_TDM_SLOT_LAST,
+ sap_tdm_slot_last ? TAS6424_SAP_TDM_SLOT_LAST : 0);
+
+ return 0;
+}
+
+static int tas6424_mute(struct snd_soc_dai *dai, int mute)
+{
+ struct snd_soc_codec *codec = dai->codec;
+ unsigned int val;
+
+ dev_dbg(codec->dev, "%s() mute=%d\n", __func__, mute);
+
+ if (mute)
+ val = TAS6424_ALL_STATE_MUTE;
+ else
+ val = TAS6424_ALL_STATE_PLAY;
+
+ snd_soc_write(codec, TAS6424_CH_STATE_CTRL, val);
+
+ return 0;
+}
+
+static int tas6424_power_off(struct snd_soc_codec *codec)
+{
+ struct tas6424_data *tas6424 = snd_soc_codec_get_drvdata(codec);
+ int ret;
+
+ snd_soc_write(codec, TAS6424_CH_STATE_CTRL, TAS6424_ALL_STATE_HIZ);
+
+ regcache_cache_only(tas6424->regmap, true);
+ regcache_mark_dirty(tas6424->regmap);
+
+ ret = regulator_bulk_disable(ARRAY_SIZE(tas6424->supplies),
+ tas6424->supplies);
+ if (ret < 0) {
+ dev_err(codec->dev, "failed to disable supplies: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int tas6424_power_on(struct snd_soc_codec *codec)
+{
+ struct tas6424_data *tas6424 = snd_soc_codec_get_drvdata(codec);
+ int ret;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(tas6424->supplies),
+ tas6424->supplies);
+ if (ret < 0) {
+ dev_err(codec->dev, "failed to enable supplies: %d\n", ret);
+ return ret;
+ }
+
+ regcache_cache_only(tas6424->regmap, false);
+
+ ret = regcache_sync(tas6424->regmap);
+ if (ret < 0) {
+ dev_err(codec->dev, "failed to sync regcache: %d\n", ret);
+ return ret;
+ }
+
+ snd_soc_write(codec, TAS6424_CH_STATE_CTRL, TAS6424_ALL_STATE_MUTE);
+
+ /* any time we come out of HIZ, the output channels automatically run DC
+ * load diagnostics, wait here until this completes
+ */
+ msleep(230);
+
+ return 0;
+}
+
+static int tas6424_set_bias_level(struct snd_soc_codec *codec,
+ enum snd_soc_bias_level level)
+{
+ dev_dbg(codec->dev, "%s() level=%d\n", __func__, level);
+
+ switch (level) {
+ case SND_SOC_BIAS_ON:
+ case SND_SOC_BIAS_PREPARE:
+ break;
+ case SND_SOC_BIAS_STANDBY:
+ if (snd_soc_codec_get_bias_level(codec) == SND_SOC_BIAS_OFF)
+ tas6424_power_on(codec);
+ break;
+ case SND_SOC_BIAS_OFF:
+ tas6424_power_off(codec);
+ break;
+ }
+
+ return 0;
+}
+
+static struct snd_soc_codec_driver soc_codec_dev_tas6424 = {
+ .set_bias_level = tas6424_set_bias_level,
+ .idle_bias_off = true,
+
+ .component_driver = {
+ .controls = tas6424_snd_controls,
+ .num_controls = ARRAY_SIZE(tas6424_snd_controls),
+ .dapm_widgets = tas6424_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(tas6424_dapm_widgets),
+ .dapm_routes = tas6424_audio_map,
+ .num_dapm_routes = ARRAY_SIZE(tas6424_audio_map),
+ },
+};
+
+static struct snd_soc_dai_ops tas6424_speaker_dai_ops = {
+ .hw_params = tas6424_hw_params,
+ .set_fmt = tas6424_set_dai_fmt,
+ .set_tdm_slot = tas6424_set_dai_tdm_slot,
+ .digital_mute = tas6424_mute,
+};
+
+static struct snd_soc_dai_driver tas6424_dai[] = {
+ {
+ .name = "tas6424-amplifier",
+ .playback = {
+ .stream_name = "Playback",
+ .channels_min = 1,
+ .channels_max = 4,
+ .rates = TAS6424_RATES,
+ .formats = TAS6424_FORMATS,
+ },
+ .ops = &tas6424_speaker_dai_ops,
+ },
+};
+
+static void tas6424_fault_check_work(struct work_struct *work)
+{
+ struct tas6424_data *tas6424 = container_of(work, struct tas6424_data,
+ fault_check_work.work);
+ struct device *dev = tas6424->dev;
+ unsigned int reg;
+ int ret;
+
+ ret = regmap_read(tas6424->regmap, TAS6424_GLOB_FAULT1, ®);
+ if (ret < 0) {
+ dev_err(dev, "failed to read FAULT1 register: %d\n", ret);
+ goto out;
+ }
+
+ /*
+ * Ignore any clock faults as there is no clean way to check for them.
+ * We would need to start checking for those faults *after* the SAIF
+ * stream has been setup, and stop checking *before* the stream is
+ * stopped to avoid any false-positives. However there are no
+ * appropriate hooks to monitor these events.
+ */
+ reg &= TAS6424_FAULT_PVDD_OV |
+ TAS6424_FAULT_VBAT_OV |
+ TAS6424_FAULT_PVDD_UV |
+ TAS6424_FAULT_VBAT_UV;
+
+ if (reg)
+ goto check_global_fault2_reg;
+
+ /*
+ * Only flag errors once for a given occurrence. This is needed as
+ * the TAS6424 will take time clearing the fault condition internally
+ * during which we don't want to bombard the system with the same
+ * error message over and over.
+ */
+ if ((reg & TAS6424_FAULT_PVDD_OV) && !(tas6424->last_fault1 & TAS6424_FAULT_PVDD_OV))
+ dev_crit(dev, "experienced a PVDD overvoltage fault\n");
+
+ if ((reg & TAS6424_FAULT_VBAT_OV) && !(tas6424->last_fault1 & TAS6424_FAULT_VBAT_OV))
+ dev_crit(dev, "experienced a VBAT overvoltage fault\n");
+
+ if ((reg & TAS6424_FAULT_PVDD_UV) && !(tas6424->last_fault1 & TAS6424_FAULT_PVDD_UV))
+ dev_crit(dev, "experienced a PVDD undervoltage fault\n");
+
+ if ((reg & TAS6424_FAULT_VBAT_UV) && !(tas6424->last_fault1 & TAS6424_FAULT_VBAT_UV))
+ dev_crit(dev, "experienced a VBAT undervoltage fault\n");
+
+ /* Store current fault1 value so we can detect any changes next time */
+ tas6424->last_fault1 = reg;
+
+check_global_fault2_reg:
+ ret = regmap_read(tas6424->regmap, TAS6424_GLOB_FAULT2, ®);
+ if (ret < 0) {
+ dev_err(dev, "failed to read FAULT2 register: %d\n", ret);
+ goto out;
+ }
+
+ reg &= TAS6424_FAULT_OTSD |
+ TAS6424_FAULT_OTSD_CH1 |
+ TAS6424_FAULT_OTSD_CH2 |
+ TAS6424_FAULT_OTSD_CH3 |
+ TAS6424_FAULT_OTSD_CH4;
+
+ if (!reg)
+ goto check_warn_reg;
+
+ if ((reg & TAS6424_FAULT_OTSD) && !(tas6424->last_fault2 & TAS6424_FAULT_OTSD))
+ dev_crit(dev, "experienced a global overtemp shutdown\n");
+
+ if ((reg & TAS6424_FAULT_OTSD_CH1) && !(tas6424->last_fault2 & TAS6424_FAULT_OTSD_CH1))
+ dev_crit(dev, "experienced an overtemp shutdown on CH1\n");
+
+ if ((reg & TAS6424_FAULT_OTSD_CH2) && !(tas6424->last_fault2 & TAS6424_FAULT_OTSD_CH2))
+ dev_crit(dev, "experienced an overtemp shutdown on CH2\n");
+
+ if ((reg & TAS6424_FAULT_OTSD_CH3) && !(tas6424->last_fault2 & TAS6424_FAULT_OTSD_CH3))
+ dev_crit(dev, "experienced an overtemp shutdown on CH3\n");
+
+ if ((reg & TAS6424_FAULT_OTSD_CH4) && !(tas6424->last_fault2 & TAS6424_FAULT_OTSD_CH4))
+ dev_crit(dev, "experienced an overtemp shutdown on CH4\n");
+
+ /* Store current fault2 value so we can detect any changes next time */
+ tas6424->last_fault2 = reg;
+
+check_warn_reg:
+ ret = regmap_read(tas6424->regmap, TAS6424_WARN, ®);
+ if (ret < 0) {
+ dev_err(dev, "failed to read WARN register: %d\n", ret);
+ goto out;
+ }
+
+ reg &= TAS6424_WARN_VDD_UV |
+ TAS6424_WARN_VDD_POR |
+ TAS6424_WARN_VDD_OTW |
+ TAS6424_WARN_VDD_OTW_CH1 |
+ TAS6424_WARN_VDD_OTW_CH2 |
+ TAS6424_WARN_VDD_OTW_CH3 |
+ TAS6424_WARN_VDD_OTW_CH4;
+
+ if (!reg)
+ goto out;
+
+ if ((reg & TAS6424_WARN_VDD_UV) && !(tas6424->last_warn & TAS6424_WARN_VDD_UV))
+ dev_warn(dev, "experienced a VDD under voltage condition\n");
+
+ if ((reg & TAS6424_WARN_VDD_POR) && !(tas6424->last_warn & TAS6424_WARN_VDD_POR))
+ dev_warn(dev, "experienced a VDD POR condition\n");
+
+ if ((reg & TAS6424_WARN_VDD_OTW) && !(tas6424->last_warn & TAS6424_WARN_VDD_OTW))
+ dev_warn(dev, "experienced a global overtemp warning\n");
+
+ if ((reg & TAS6424_WARN_VDD_OTW_CH1) && !(tas6424->last_warn & TAS6424_WARN_VDD_OTW_CH1))
+ dev_warn(dev, "experienced an overtemp warning on CH1\n");
+
+ if ((reg & TAS6424_WARN_VDD_OTW_CH2) && !(tas6424->last_warn & TAS6424_WARN_VDD_OTW_CH2))
+ dev_warn(dev, "experienced an overtemp warning on CH2\n");
+
+ if ((reg & TAS6424_WARN_VDD_OTW_CH3) && !(tas6424->last_warn & TAS6424_WARN_VDD_OTW_CH3))
+ dev_warn(dev, "experienced an overtemp warning on CH3\n");
+
+ if ((reg & TAS6424_WARN_VDD_OTW_CH4) && !(tas6424->last_warn & TAS6424_WARN_VDD_OTW_CH4))
+ dev_warn(dev, "experienced an overtemp warning on CH4\n");
+
+ /* Store current warn value so we can detect any changes next time */
+ tas6424->last_warn = reg;
+
+ /* Clear any faults by toggling the CLEAR_FAULT control bit */
+ ret = regmap_write_bits(tas6424->regmap, TAS6424_MISC_CTRL3,
+ TAS6424_CLEAR_FAULT, TAS6424_CLEAR_FAULT);
+ if (ret < 0)
+ dev_err(dev, "failed to write MISC_CTRL3 register: %d\n", ret);
+
+ ret = regmap_write_bits(tas6424->regmap, TAS6424_MISC_CTRL3,
+ TAS6424_CLEAR_FAULT, 0);
+ if (ret < 0)
+ dev_err(dev, "failed to write MISC_CTRL3 register: %d\n", ret);
+
+out:
+ /* Schedule the next fault check at the specified interval */
+ schedule_delayed_work(&tas6424->fault_check_work,
+ msecs_to_jiffies(TAS6424_FAULT_CHECK_INTERVAL));
+}
+
+static const struct reg_default tas6424_reg_defaults[] = {
+ { TAS6424_MODE_CTRL, 0x00 },
+ { TAS6424_MISC_CTRL1, 0x32 },
+ { TAS6424_MISC_CTRL2, 0x62 },
+ { TAS6424_SAP_CTRL, 0x04 },
+ { TAS6424_CH_STATE_CTRL, 0x55 },
+ { TAS6424_CH1_VOL_CTRL, 0xcf },
+ { TAS6424_CH2_VOL_CTRL, 0xcf },
+ { TAS6424_CH3_VOL_CTRL, 0xcf },
+ { TAS6424_CH4_VOL_CTRL, 0xcf },
+ { TAS6424_DC_DIAG_CTRL1, 0x00 },
+ { TAS6424_DC_DIAG_CTRL2, 0x11 },
+ { TAS6424_DC_DIAG_CTRL3, 0x11 },
+ { TAS6424_PIN_CTRL, 0xff },
+ { TAS6424_AC_DIAG_CTRL1, 0x00 },
+ { TAS6424_MISC_CTRL3, 0x00 },
+ { TAS6424_CLIP_CTRL, 0x01 },
+ { TAS6424_CLIP_WINDOW, 0x14 },
+ { TAS6424_CLIP_WARN, 0x00 },
+ { TAS6424_CBC_STAT, 0x00 },
+ { TAS6424_MISC_CTRL4, 0x40 },
+};
+
+static bool tas6424_is_writable_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case TAS6424_MODE_CTRL:
+ case TAS6424_MISC_CTRL1:
+ case TAS6424_MISC_CTRL2:
+ case TAS6424_SAP_CTRL:
+ case TAS6424_CH_STATE_CTRL:
+ case TAS6424_CH1_VOL_CTRL:
+ case TAS6424_CH2_VOL_CTRL:
+ case TAS6424_CH3_VOL_CTRL:
+ case TAS6424_CH4_VOL_CTRL:
+ case TAS6424_DC_DIAG_CTRL1:
+ case TAS6424_DC_DIAG_CTRL2:
+ case TAS6424_DC_DIAG_CTRL3:
+ case TAS6424_PIN_CTRL:
+ case TAS6424_AC_DIAG_CTRL1:
+ case TAS6424_MISC_CTRL3:
+ case TAS6424_CLIP_CTRL:
+ case TAS6424_CLIP_WINDOW:
+ case TAS6424_CLIP_WARN:
+ case TAS6424_CBC_STAT:
+ case TAS6424_MISC_CTRL4:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool tas6424_is_volatile_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case TAS6424_DC_LOAD_DIAG_REP12:
+ case TAS6424_DC_LOAD_DIAG_REP34:
+ case TAS6424_DC_LOAD_DIAG_REPLO:
+ case TAS6424_CHANNEL_STATE:
+ case TAS6424_CHANNEL_FAULT:
+ case TAS6424_GLOB_FAULT1:
+ case TAS6424_GLOB_FAULT2:
+ case TAS6424_WARN:
+ case TAS6424_AC_LOAD_DIAG_REP1:
+ case TAS6424_AC_LOAD_DIAG_REP2:
+ case TAS6424_AC_LOAD_DIAG_REP3:
+ case TAS6424_AC_LOAD_DIAG_REP4:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static const struct regmap_config tas6424_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .writeable_reg = tas6424_is_writable_reg,
+ .volatile_reg = tas6424_is_volatile_reg,
+
+ .max_register = TAS6424_MAX,
+ .reg_defaults = tas6424_reg_defaults,
+ .num_reg_defaults = ARRAY_SIZE(tas6424_reg_defaults),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id tas6424_of_ids[] = {
+ { .compatible = "ti,tas6424", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tas6424_of_ids);
+#endif
+
+static int tas6424_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = &client->dev;
+ struct tas6424_data *tas6424;
+ int ret;
+ int i;
+
+ tas6424 = devm_kzalloc(dev, sizeof(*tas6424), GFP_KERNEL);
+ if (!tas6424)
+ return -ENOMEM;
+ dev_set_drvdata(dev, tas6424);
+
+ tas6424->dev = dev;
+
+ tas6424->regmap = devm_regmap_init_i2c(client, &tas6424_regmap_config);
+ if (IS_ERR(tas6424->regmap)) {
+ ret = PTR_ERR(tas6424->regmap);
+ dev_err(dev, "unable to allocate register map: %d\n", ret);
+ return ret;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(tas6424->supplies); i++)
+ tas6424->supplies[i].supply = tas6424_supply_names[i];
+ ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(tas6424->supplies),
+ tas6424->supplies);
+ if (ret) {
+ dev_err(dev, "unable to request supplies: %d\n", ret);
+ return ret;
+ }
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(tas6424->supplies),
+ tas6424->supplies);
+ if (ret) {
+ dev_err(dev, "unable to enable supplies: %d\n", ret);
+ return ret;
+ }
+
+ /* Reset device to establish well-defined startup state */
+ ret = regmap_update_bits(tas6424->regmap, TAS6424_MODE_CTRL,
+ TAS6424_RESET, TAS6424_RESET);
+ if (ret) {
+ dev_err(dev, "unable to reset device: %d\n", ret);
+ return ret;
+ }
+
+ INIT_DELAYED_WORK(&tas6424->fault_check_work, tas6424_fault_check_work);
+
+ ret = snd_soc_register_codec(dev, &soc_codec_dev_tas6424,
+ tas6424_dai, ARRAY_SIZE(tas6424_dai));
+ if (ret < 0) {
+ dev_err(dev, "unable to register codec: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int tas6424_i2c_remove(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct tas6424_data *tas6424 = dev_get_drvdata(dev);
+ int ret;
+
+ snd_soc_unregister_codec(dev);
+
+ cancel_delayed_work_sync(&tas6424->fault_check_work);
+
+ ret = regulator_bulk_disable(ARRAY_SIZE(tas6424->supplies),
+ tas6424->supplies);
+ if (ret < 0) {
+ dev_err(dev, "unable to disable supplies: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct i2c_device_id tas6424_i2c_ids[] = {
+ { "tas6424", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, tas6424_i2c_ids);
+
+static struct i2c_driver tas6424_i2c_driver = {
+ .driver = {
+ .name = "tas6424",
+ .of_match_table = of_match_ptr(tas6424_of_ids),
+ },
+ .probe = tas6424_i2c_probe,
+ .remove = tas6424_i2c_remove,
+ .id_table = tas6424_i2c_ids,
+};
+module_i2c_driver(tas6424_i2c_driver);
+
+MODULE_AUTHOR("Andreas Dannenberg <dannenberg@ti.com>");
+MODULE_AUTHOR("Andrew F. Davis <afd@ti.com>");
+MODULE_DESCRIPTION("TAS6424 Audio amplifier driver");
+MODULE_LICENSE("GPL v2");
diff --git a/sound/soc/codecs/tas6424.h b/sound/soc/codecs/tas6424.h
new file mode 100644
index 000000000000..430588328a06
--- /dev/null
+++ b/sound/soc/codecs/tas6424.h
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ALSA SoC Texas Instruments TAS6424 Quad-Channel Audio Amplifier
+ *
+ * Copyright (C) 2016-2017 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Andreas Dannenberg <dannenberg@ti.com>
+ * Andrew F. Davis <afd@ti.com>
+ */
+
+#ifndef __TAS6424_H__
+#define __TAS6424_H__
+
+#define TAS6424_RATES (SNDRV_PCM_RATE_44100 | \
+ SNDRV_PCM_RATE_48000 | \
+ SNDRV_PCM_RATE_96000)
+
+#define TAS6424_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
+ SNDRV_PCM_FMTBIT_S24_LE)
+
+/* Register Address Map */
+#define TAS6424_MODE_CTRL 0x00
+#define TAS6424_MISC_CTRL1 0x01
+#define TAS6424_MISC_CTRL2 0x02
+#define TAS6424_SAP_CTRL 0x03
+#define TAS6424_CH_STATE_CTRL 0x04
+#define TAS6424_CH1_VOL_CTRL 0x05
+#define TAS6424_CH2_VOL_CTRL 0x06
+#define TAS6424_CH3_VOL_CTRL 0x07
+#define TAS6424_CH4_VOL_CTRL 0x08
+#define TAS6424_DC_DIAG_CTRL1 0x09
+#define TAS6424_DC_DIAG_CTRL2 0x0a
+#define TAS6424_DC_DIAG_CTRL3 0x0b
+#define TAS6424_DC_LOAD_DIAG_REP12 0x0c
+#define TAS6424_DC_LOAD_DIAG_REP34 0x0d
+#define TAS6424_DC_LOAD_DIAG_REPLO 0x0e
+#define TAS6424_CHANNEL_STATE 0x0f
+#define TAS6424_CHANNEL_FAULT 0x10
+#define TAS6424_GLOB_FAULT1 0x11
+#define TAS6424_GLOB_FAULT2 0x12
+#define TAS6424_WARN 0x13
+#define TAS6424_PIN_CTRL 0x14
+#define TAS6424_AC_DIAG_CTRL1 0x15
+#define TAS6424_AC_DIAG_CTRL2 0x16
+#define TAS6424_AC_LOAD_DIAG_REP1 0x17
+#define TAS6424_AC_LOAD_DIAG_REP2 0x18
+#define TAS6424_AC_LOAD_DIAG_REP3 0x19
+#define TAS6424_AC_LOAD_DIAG_REP4 0x1a
+#define TAS6424_MISC_CTRL3 0x21
+#define TAS6424_CLIP_CTRL 0x22
+#define TAS6424_CLIP_WINDOW 0x23
+#define TAS6424_CLIP_WARN 0x24
+#define TAS6424_CBC_STAT 0x25
+#define TAS6424_MISC_CTRL4 0x26
+#define TAS6424_MAX TAS6424_MISC_CTRL4
+
+/* TAS6424_MODE_CTRL_REG */
+#define TAS6424_RESET BIT(7)
+
+/* TAS6424_SAP_CTRL_REG */
+#define TAS6424_SAP_RATE_MASK GENMASK(7, 6)
+#define TAS6424_SAP_RATE_44100 (0x00 << 6)
+#define TAS6424_SAP_RATE_48000 (0x01 << 6)
+#define TAS6424_SAP_RATE_96000 (0x02 << 6)
+#define TAS6424_SAP_TDM_SLOT_LAST BIT(5)
+#define TAS6424_SAP_TDM_SLOT_SZ_16 BIT(4)
+#define TAS6424_SAP_TDM_SLOT_SWAP BIT(3)
+#define TAS6424_SAP_FMT_MASK GENMASK(2, 0)
+#define TAS6424_SAP_RIGHTJ_24 (0x00 << 0)
+#define TAS6424_SAP_RIGHTJ_20 (0x01 << 0)
+#define TAS6424_SAP_RIGHTJ_18 (0x02 << 0)
+#define TAS6424_SAP_RIGHTJ_16 (0x03 << 0)
+#define TAS6424_SAP_I2S (0x04 << 0)
+#define TAS6424_SAP_LEFTJ (0x05 << 0)
+#define TAS6424_SAP_DSP (0x06 << 0)
+
+/* TAS6424_CH_STATE_CTRL_REG */
+#define TAS6424_CH1_STATE_MASK GENMASK(7, 6)
+#define TAS6424_CH1_STATE_PLAY (0x00 << 6)
+#define TAS6424_CH1_STATE_HIZ (0x01 << 6)
+#define TAS6424_CH1_STATE_MUTE (0x02 << 6)
+#define TAS6424_CH1_STATE_DIAG (0x03 << 6)
+#define TAS6424_CH2_STATE_MASK GENMASK(5, 4)
+#define TAS6424_CH2_STATE_PLAY (0x00 << 4)
+#define TAS6424_CH2_STATE_HIZ (0x01 << 4)
+#define TAS6424_CH2_STATE_MUTE (0x02 << 4)
+#define TAS6424_CH2_STATE_DIAG (0x03 << 4)
+#define TAS6424_CH3_STATE_MASK GENMASK(3, 2)
+#define TAS6424_CH3_STATE_PLAY (0x00 << 2)
+#define TAS6424_CH3_STATE_HIZ (0x01 << 2)
+#define TAS6424_CH3_STATE_MUTE (0x02 << 2)
+#define TAS6424_CH3_STATE_DIAG (0x03 << 2)
+#define TAS6424_CH4_STATE_MASK GENMASK(1, 0)
+#define TAS6424_CH4_STATE_PLAY (0x00 << 0)
+#define TAS6424_CH4_STATE_HIZ (0x01 << 0)
+#define TAS6424_CH4_STATE_MUTE (0x02 << 0)
+#define TAS6424_CH4_STATE_DIAG (0x03 << 0)
+#define TAS6424_ALL_STATE_PLAY (TAS6424_CH1_STATE_PLAY | \
+ TAS6424_CH2_STATE_PLAY | \
+ TAS6424_CH3_STATE_PLAY | \
+ TAS6424_CH4_STATE_PLAY)
+#define TAS6424_ALL_STATE_HIZ (TAS6424_CH1_STATE_HIZ | \
+ TAS6424_CH2_STATE_HIZ | \
+ TAS6424_CH3_STATE_HIZ | \
+ TAS6424_CH4_STATE_HIZ)
+#define TAS6424_ALL_STATE_MUTE (TAS6424_CH1_STATE_MUTE | \
+ TAS6424_CH2_STATE_MUTE | \
+ TAS6424_CH3_STATE_MUTE | \
+ TAS6424_CH4_STATE_MUTE)
+#define TAS6424_ALL_STATE_DIAG (TAS6424_CH1_STATE_DIAG | \
+ TAS6424_CH2_STATE_DIAG | \
+ TAS6424_CH3_STATE_DIAG | \
+ TAS6424_CH4_STATE_DIAG)
+
+/* TAS6424_GLOB_FAULT1_REG */
+#define TAS6424_FAULT_CLOCK BIT(4)
+#define TAS6424_FAULT_PVDD_OV BIT(3)
+#define TAS6424_FAULT_VBAT_OV BIT(2)
+#define TAS6424_FAULT_PVDD_UV BIT(1)
+#define TAS6424_FAULT_VBAT_UV BIT(0)
+
+/* TAS6424_GLOB_FAULT2_REG */
+#define TAS6424_FAULT_OTSD BIT(4)
+#define TAS6424_FAULT_OTSD_CH1 BIT(3)
+#define TAS6424_FAULT_OTSD_CH2 BIT(2)
+#define TAS6424_FAULT_OTSD_CH3 BIT(1)
+#define TAS6424_FAULT_OTSD_CH4 BIT(0)
+
+/* TAS6424_WARN_REG */
+#define TAS6424_WARN_VDD_UV BIT(6)
+#define TAS6424_WARN_VDD_POR BIT(5)
+#define TAS6424_WARN_VDD_OTW BIT(4)
+#define TAS6424_WARN_VDD_OTW_CH1 BIT(3)
+#define TAS6424_WARN_VDD_OTW_CH2 BIT(2)
+#define TAS6424_WARN_VDD_OTW_CH3 BIT(1)
+#define TAS6424_WARN_VDD_OTW_CH4 BIT(0)
+
+/* TAS6424_MISC_CTRL3_REG */
+#define TAS6424_CLEAR_FAULT BIT(7)
+#define TAS6424_PBTL_CH_SEL BIT(6)
+#define TAS6424_MASK_CBC_WARN BIT(5)
+#define TAS6424_MASK_VDD_UV BIT(4)
+#define TAS6424_OTSD_AUTO_RECOVERY BIT(3)
+
+#endif /* __TAS6424_H__ */
--
2.15.0
^ permalink raw reply related
* Re: [PATCH v2 08/19] ASoC: tlv320aic31xx: Switch GPIO handling to use gpiod_* API
From: Mark Brown @ 2017-12-06 12:46 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Mark Rutland, devicetree, alsa-devel, Tony Lindgren,
Liam Girdwood, linux-kernel, Rob Herring, Benoît Cousson
In-Reply-To: <17fcc926-9ee8-1229-ea3d-f38347cb9a23@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 683 bytes --]
On Tue, Dec 05, 2017 at 03:23:49PM -0600, Andrew F. Davis wrote:
> On 12/04/2017 10:47 AM, Andrew F. Davis wrote:
> > Kbuild bot seems mad a this one, looks like I need to include
> > linux/gpio/consumer.h, will fix for v3.
> Looks like you already have this in your -next branch, how do you want
> this fix, I can send a delta patch with the added include, a new v3
> version that you can replace the patch in-tree with, or if it's easier
> for you manually fix in-tree?
As the patch applied mail says:
| If any updates are required or you are submitting further changes they
| should be sent as incremental updates against current git, existing
| patches will not be replaced.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH v2 09/19] ASoC: tlv320aic31xx: Remove platform data
From: Mark Brown @ 2017-12-06 12:45 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Mark Rutland, devicetree, alsa-devel, Tony Lindgren,
Liam Girdwood, linux-kernel, Rob Herring, Benoît Cousson
In-Reply-To: <4fee76ef-e518-69b6-3bcc-f65b0a31cacc@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 797 bytes --]
On Tue, Dec 05, 2017 at 03:20:19PM -0600, Andrew F. Davis wrote:
> On 12/01/2017 07:26 AM, Mark Brown wrote:
> > The advantage being...? Not all architectures use DT or ACPI so it's
> > not clear that this is a step forwards in itself.
> Simplifies the code in several places, and you don't need to use DT or
> ACPI, it probes just fine anyway you normally add an I2C device.
> All we are dropping here is the platform_data way of specifying mic-bias
> voltage, which if you are wanting to do that in an out-of-tree board
> file, then I'm sure you can locally modify this driver to use your
> wanted voltage setting by default.
Then if you want to upstream the driver you'll have to add the platform
data support again. Like I say not all architectures have anything
other than board files.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH v2 7/7] dt-bindings: tda998x: add the calibration gpio
From: Russell King @ 2017-12-06 12:35 UTC (permalink / raw)
To: David Airlie, Hans Verkuil
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Rob Herring,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171206123452.GA13127-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Add the optional calibration gpio for integrated TDA9950 CEC support.
This GPIO corresponds with the interrupt from the TDA998x, as the
calibration requires driving the interrupt pin low.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
Documentation/devicetree/bindings/display/bridge/tda998x.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
index 24cc2466185a..1a4eaca40d94 100644
--- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
+++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
@@ -27,6 +27,9 @@ Required properties;
in question is used. The implementation allows one or two DAIs. If two
DAIs are defined, they must be of different type.
+ - nxp,calib-gpios: calibration GPIO, which must correspond with the
+ gpio used for the TDA998x interrupt pin.
+
[1] Documentation/sound/alsa/soc/DAI.txt
[2] include/dt-bindings/display/tda998x.h
--
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
* Re: [PATCH v4 1/2] dt-bindings: sound: add bindings for TAS6424
From: Mark Brown @ 2017-12-06 12:24 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Mark Rutland, devicetree, alsa-devel, Liam Girdwood, linux-kernel,
Rob Herring
In-Reply-To: <20171205155412.20137-2-afd@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 303 bytes --]
On Tue, Dec 05, 2017 at 09:54:11AM -0600, Andrew F. Davis wrote:
> From: Michael Stecklein <m-stecklein@ti.com>
>
> Add the bindings for the TAS6424 digital amplifier.
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] cpufreq: Add DVFS support for Armada 37xx
From: Gregory CLEMENT @ 2017-12-06 12:24 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, linux-pm, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Rob Herring, devicetree, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits, Evan Wang
In-Reply-To: <20171205055414.yghqdxg2but34n4i@vireshk-mac-ubuntu>
Hi Viresh,
On mar., déc. 05 2017, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 01-12-17, 12:25, Gregory CLEMENT wrote:
>> This patch adds DVFS support for the Armada 37xx SoCs
>>
>> There are up to four CPU frequency loads for Armada 37xx controlled by
>> the hardware.
>>
>> This driver associates the CPU load level to a frequency, then the
>> hardware will switch while selecting a load level.
>>
>> The hardware also can associate a voltage for each level (AVS support)
>> but it is not yet supported
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> drivers/cpufreq/Kconfig.arm | 7 +
>> drivers/cpufreq/Makefile | 1 +
>> drivers/cpufreq/armada-37xx-cpufreq.c | 241 ++++++++++++++++++++++++++++++++++
>> 3 files changed, 249 insertions(+)
>> create mode 100644 drivers/cpufreq/armada-37xx-cpufreq.c
>>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index 17625115c67f..3018ff0d068f 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -19,6 +19,13 @@ config ACPI_CPPC_CPUFREQ
>>
>> If in doubt, say N.
>>
>> +config ARM_ARMADA_37XX_CPUFREQ
>> + tristate "Armada 37xx CPUFreq support"
>> + depends on ARCH_MVEBU
>> + help
>> + This adds the CPUFreq driver support for Marvell Armada 37xx SoCs.
>> + The Armada 37xx PMU supports 4 frequency and VDD levels.
>> +
>> # big LITTLE core layer and glue drivers
>> config ARM_BIG_LITTLE_CPUFREQ
>> tristate "Generic ARM big LITTLE CPUfreq driver"
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index d762e76887e7..e07715ce8844 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -52,6 +52,7 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ) += arm_big_little.o
>> # LITTLE drivers, so that it is probed last.
>> obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o
>>
>> +obj-$(CONFIG_ARM_ARMADA_37XX_CPUFREQ) += armada-37xx-cpufreq.o
>> obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ) += brcmstb-avs-cpufreq.o
>> obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
>> obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
>> diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c
>> new file mode 100644
>> index 000000000000..40c9a744cc6e
>> --- /dev/null
>> +++ b/drivers/cpufreq/armada-37xx-cpufreq.c
>> @@ -0,0 +1,241 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * CPU frequency scaling support for Armada 37xx platform.
>> + *
>> + * Copyright (C) 2017 Marvell
>> + *
>> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/cpu.h>
>> +#include <linux/cpufreq.h>
>> +#include <linux/err.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/module.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pm_opp.h>
>> +#include <linux/regmap.h>
>> +#include <linux/slab.h>
>> +
>> +/* Power management in North Bridge register set */
>> +#define ARMADA_37XX_NB_L0L1 0x18
>> +#define ARMADA_37XX_NB_L2L3 0x1C
>> +#define ARMADA_37XX_NB_TBG_DIV_OFF 13
>> +#define ARMADA_37XX_NB_TBG_DIV_MASK 0x7
>> +#define ARMADA_37XX_NB_CLK_SEL_OFF 11
>> +#define ARMADA_37XX_NB_CLK_SEL_MASK 0x1
>> +#define ARMADA_37XX_NB_CLK_SEL_TBG 0x1
>> +#define ARMADA_37XX_NB_TBG_SEL_OFF 9
>> +#define ARMADA_37XX_NB_TBG_SEL_MASK 0x3
>> +#define ARMADA_37XX_NB_VDD_SEL_OFF 6
>> +#define ARMADA_37XX_NB_VDD_SEL_MASK 0x3
>> +#define ARMADA_37XX_NB_CONFIG_SHIFT 16
>
> Looks like you have added tabs after #define as well? Perhaps a space
> is good enough there.
OK
>
>> +#define ARMADA_37XX_NB_DYN_MOD 0x24
>> +#define ARMADA_37XX_NB_CLK_SEL_EN BIT(26)
>> +#define ARMADA_37XX_NB_TBG_EN BIT(28)
>> +#define ARMADA_37XX_NB_DIV_EN BIT(29)
>> +#define ARMADA_37XX_NB_VDD_EN BIT(30)
>> +#define ARMADA_37XX_NB_DFS_EN BIT(31)
>> +#define ARMADA_37XX_NB_CPU_LOAD 0x30
>> +#define ARMADA_37XX_NB_CPU_LOAD_MASK 0x3
>> +#define ARMADA_37XX_DVFS_LOAD_0 0
>> +#define ARMADA_37XX_DVFS_LOAD_1 1
>> +#define ARMADA_37XX_DVFS_LOAD_2 2
>> +#define ARMADA_37XX_DVFS_LOAD_3 3
>> +
>> +/*
>> + * On Armada 37xx the Power management manages 4 level of CPU load,
>> + * each level can be associated with a CPU clock source, a CPU
>> + * divider, a VDD level, etc...
>> + */
>> +#define LOAD_LEVEL_NR 4
>> +
>> +struct armada_37xx_dvfs {
>> + u32 cpu_freq_max;
>> + u8 divider[LOAD_LEVEL_NR];
>> +};
>> +
>> +static struct armada_37xx_dvfs armada_37xx_dvfs[] = {
>> + {.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} },
>> + {.cpu_freq_max = 1000*1000*1000, .divider = {1, 2, 4, 5} },
>> + {.cpu_freq_max = 800*1000*1000, .divider = {1, 2, 3, 4} },
>> + {.cpu_freq_max = 600*1000*1000, .divider = {2, 4, 5, 6} },
>> +};
>> +
>> +static struct armada_37xx_dvfs *armada_37xx_cpu_freq_info_get(u32 freq)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(armada_37xx_dvfs); i++) {
>> + if (freq == armada_37xx_dvfs[i].cpu_freq_max)
>> + return &armada_37xx_dvfs[i];
>> + }
>> +
>> + pr_err("Unsupported CPU frequency %d MHz\n", freq/1000000);
>> + return NULL;
>> +}
>> +
>> +/*
>> + * Setup the four level managed by the hardware. Once the four level
>> + * will be configured then the DVFS will be enabled.
>> + */
>> +static void __init armada37xx_cpufreq_dvfs_setup(struct regmap *base,
>> + struct clk *clk, u8 *divider)
>> +{
>> + int load_level;
>> + struct clk *parent;
>> +
>> + for (load_level = 0; load_level < LOAD_LEVEL_NR; load_level++) {
>> + unsigned int reg, mask, val, offset = 0;
>> +
>> + if (load_level <= ARMADA_37XX_DVFS_LOAD_1)
>> + reg = ARMADA_37XX_NB_L0L1;
>> + else
>> + reg = ARMADA_37XX_NB_L2L3;
>> +
>> + if (load_level == ARMADA_37XX_DVFS_LOAD_0 ||
>> + load_level == ARMADA_37XX_DVFS_LOAD_2)
>> + offset += ARMADA_37XX_NB_CONFIG_SHIFT;
>> +
>> + /* Set cpu clock source, for all the level we use TBG */
>> + val = ARMADA_37XX_NB_CLK_SEL_TBG << ARMADA_37XX_NB_CLK_SEL_OFF;
>> + mask = (ARMADA_37XX_NB_CLK_SEL_MASK
>> + << ARMADA_37XX_NB_CLK_SEL_OFF);
>> +
>> + /*
>> + * Set cpu divider based on the pre-computed array in
>> + * order to have balanced step.
>> + */
>> + val |= divider[load_level] << ARMADA_37XX_NB_TBG_DIV_OFF;
>> + mask |= (ARMADA_37XX_NB_TBG_DIV_MASK
>> + << ARMADA_37XX_NB_TBG_DIV_OFF);
>> +
>> + /* Set VDD divider which is actually the load level. */
>> + val |= load_level << ARMADA_37XX_NB_VDD_SEL_OFF;
>> + mask |= (ARMADA_37XX_NB_VDD_SEL_MASK
>> + << ARMADA_37XX_NB_VDD_SEL_OFF);
>> +
>> + val <<= offset;
>> + mask <<= offset;
>> +
>> + regmap_update_bits(base, reg, mask, val);
>> + }
>> +
>> + /*
>> + * Set cpu clock source, for all the level we keep the same
>> + * clock source that the one already configured. For this one
>> + * we need to use the clock framework
>> + */
>> + parent = clk_get_parent(clk);
>> + clk_set_parent(clk, parent);
>> +}
>> +
>> +static void __init armada37xx_cpufreq_disable_dvfs(struct regmap *base)
>> +{
>> + unsigned int reg = ARMADA_37XX_NB_DYN_MOD,
>> + mask = ARMADA_37XX_NB_DFS_EN;
>> +
>> + regmap_update_bits(base, reg, mask, 0);
>> +}
>> +
>> +static void __init armada37xx_cpufreq_enable_dvfs(struct regmap *base)
>> +{
>> + unsigned int val, reg = ARMADA_37XX_NB_CPU_LOAD,
>> + mask = ARMADA_37XX_NB_CPU_LOAD_MASK;
>> +
>> + /* Start with the highest load (0) */
>> + val = ARMADA_37XX_DVFS_LOAD_0;
>> + regmap_update_bits(base, reg, mask, val);
>> +
>> + /* Now enable DVFS for the CPUs */
>> + reg = ARMADA_37XX_NB_DYN_MOD;
>> + mask = ARMADA_37XX_NB_CLK_SEL_EN | ARMADA_37XX_NB_TBG_EN |
>> + ARMADA_37XX_NB_DIV_EN | ARMADA_37XX_NB_VDD_EN |
>> + ARMADA_37XX_NB_DFS_EN;
>> +
>> + regmap_update_bits(base, reg, mask, mask);
>> +}
>> +
>> +static int __init armada37xx_cpufreq_driver_init(void)
>> +{
>> + struct armada_37xx_dvfs *dvfs;
>> + struct platform_device *pdev;
>> + unsigned int cur_frequency;
>> + struct regmap *nb_pm_base;
>> + struct device *cpu_dev;
>> + int load_level, ret;
>> + struct clk *clk;
>> +
>> + nb_pm_base =
>> + syscon_regmap_lookup_by_compatible("marvell,armada-3700-nb-pm");
>> +
>> + if (IS_ERR(nb_pm_base))
>> + return -ENODEV;
>> +
>> + /* Before doing any configuration on the DVFS first, disable it */
>> + armada37xx_cpufreq_disable_dvfs(nb_pm_base);
>> +
>> + /*
>> + * On CPU 0 register the operating points supported (which are
>> + * the nominal CPU frequency and full integer divisions of
>> + * it).
>> + */
>> + cpu_dev = get_cpu_device(0);
>> + if (!cpu_dev) {
>> + dev_err(cpu_dev, "Cannot get CPU\n");
>> + return -ENODEV;
>> + }
>> +
>> + clk = clk_get(cpu_dev, 0);
>> + if (IS_ERR(clk)) {
>> + dev_err(cpu_dev, "Cannot get clock for CPU0\n");
>> + return PTR_ERR(clk);
>> + }
>> +
>> + /* Get nominal (current) CPU frequency */
>> + cur_frequency = clk_get_rate(clk);
>> + if (!cur_frequency) {
>> + dev_err(cpu_dev, "Failed to get clock rate for CPU\n");
>> + return -EINVAL;
>> + }
>> +
>> + dvfs = armada_37xx_cpu_freq_info_get(cur_frequency);
>> + if (!dvfs)
>> + return -EINVAL;
>> +
>> + armada37xx_cpufreq_dvfs_setup(nb_pm_base, clk, dvfs->divider);
>> +
>> + /*
>> + * In case of a failure of dev_pm_opp_add(), we don't bother
>> + * with cleaning up the registered OPP (there's no function to
>> + * do so),
>
> What do you mean by the comment within ()? We do have
> dev_pm_opp_remove() helper.
Actually it was a copy and paste from an other driver, I didn't check it
this was still true.
So the original comment was added in July 2014 and the
dev_pm_opp_remove() helpers was added few months later
in Nov 2014.
I will fix it and also in the other driver mvebu-cpufreq.c.
Thanks,
Gregory
>
>> and simply cancel the registration of the cpufreq
>> + * device.
>> + */
>> + for (load_level = ARMADA_37XX_DVFS_LOAD_0; load_level < LOAD_LEVEL_NR;
>> + load_level++) {
>> + unsigned long freq = dvfs->divider[load_level];
>> +
>> + ret = dev_pm_opp_add(cpu_dev, freq, 0);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + /* Now that everything is setup, enable the DVFS at hardware level */
>> + armada37xx_cpufreq_enable_dvfs(nb_pm_base);
>> +
>> + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
>> +
>> + return PTR_ERR_OR_ZERO(pdev);
>> +}
>> +/* late_initcall, to guarantee the driver is loaded after A37xx clock driver */
>> +late_initcall(armada37xx_cpufreq_driver_init);
>> +
>> +MODULE_AUTHOR("Gregory CLEMENT <gregory.clement@free-electrons.com>");
>> +MODULE_DESCRIPTION("Armada 37xx cpufreq driver");
>> +MODULE_LICENSE("GPL");
>> --
>> 2.15.0
>
> --
> viresh
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: r8a7745: Add APMU node and second CPU core
From: Geert Uytterhoeven @ 2017-12-06 12:12 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Simon Horman, Rob Herring, Mark Rutland, Magnus Damm,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux-Renesas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Chris Paterson
In-Reply-To: <1512561929-16540-1-git-send-email-fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
On Wed, Dec 6, 2017 at 1:05 PM, Fabrizio Castro
<fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org> wrote:
>
> Add DT node for the Advanced Power Management Unit (APMU), add the
> second CPU core, and use "renesas,apmu" as "enable-method".
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
> Signed-off-by: Chris Paterson <chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
> v2:
> - rebased against renesas-devel-20171205-v4.15-rc2
Seems my
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
was not added.
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: [PATCH 3/6] cpufreq: sort the drivers in ARM part
From: Gregory CLEMENT @ 2017-12-06 12:09 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, linux-pm, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Rob Herring, devicetree, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits, Evan Wang
In-Reply-To: <20171204091850.iamq5uslv3hv6bez@vireshk-mac-ubuntu>
Hi Viresh,
On lun., déc. 04 2017, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 01-12-17, 12:25, Gregory CLEMENT wrote:
>> Keep the driver files alphabetically sorted.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> drivers/cpufreq/Makefile | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index 812f9e0d01a3..d762e76887e7 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -53,22 +53,24 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ) += arm_big_little.o
>> obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o
>>
>> obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ) += brcmstb-avs-cpufreq.o
>> +obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
>
> Shouldn't we add them in ascending order of the whole config name and not just
> CPPC_CPUFREQ ?
Here it is the object name that are sorted not the CONFIG_ name. So
cppc_cpufreq comes after brcmstb-avs-cpufreq.
Thanks,
Gregory
>
> --
> viresh
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] ARM: dts: r8a7745: Add APMU node and second CPU core
From: Fabrizio Castro @ 2017-12-06 12:05 UTC (permalink / raw)
To: Simon Horman
Cc: Fabrizio Castro, Rob Herring, Mark Rutland, Magnus Damm,
Russell King, devicetree, linux-renesas-soc, linux-arm-kernel,
Chris Paterson, Geert Uytterhoeven
Add DT node for the Advanced Power Management Unit (APMU), add the
second CPU core, and use "renesas,apmu" as "enable-method".
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
Dear All,
I am reposting this patch now that its dependecy ("ARM: shmobile: rcar-gen2:
Make sure CNTVOFF is initialized on CA7/15") is part of v4.15-rc1, similarly
to patch "ARM: dts: r8a7794: Add SMP support".
v2:
- rebased against renesas-devel-20171205-v4.15-rc2
Thanks
arch/arm/boot/dts/r8a7745.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index de13e15..0fa7861 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -38,6 +38,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "renesas,apmu";
cpu0: cpu@0 {
device_type = "cpu";
@@ -49,6 +50,15 @@
next-level-cache = <&L2_CA7>;
};
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <1>;
+ clock-frequency = <1000000000>;
+ power-domains = <&sysc R8A7745_PD_CA7_CPU1>;
+ next-level-cache = <&L2_CA7>;
+ };
+
L2_CA7: cache-controller-0 {
compatible = "cache";
cache-unified;
@@ -65,6 +75,12 @@
#size-cells = <2>;
ranges;
+ apmu@e6151000 {
+ compatible = "renesas,r8a7745-apmu", "renesas,apmu";
+ reg = <0 0xe6151000 0 0x188>;
+ cpus = <&cpu0 &cpu1>;
+ };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
2.7.4
^ permalink raw reply related
* RE: [PATCH 1/8] ARM: dts: r8a7745: Add APMU node and second CPU core
From: Fabrizio Castro @ 2017-12-06 11:59 UTC (permalink / raw)
To: Geert Uytterhoeven, Simon Horman
Cc: Chris Paterson, Rob Herring, Mark Rutland, Magnus Damm,
Russell King, devicetree@vger.kernel.org, Linux-Renesas,
linux-arm-kernel@lists.infradead.org, Geert Uytterhoeven,
Fabrizio Castro, Biju Das
In-Reply-To: <TY1PR06MB089533C44E4B42D647C2CC25C0320@TY1PR06MB0895.apcprd06.prod.outlook.com>
Hello Geert, Simon,
the problems I am seeing are not related to APMU/SMP, I'll send a v2 shortly.
Thanks,
Fab
>
> Hello Geert, Simon,
>
> >
> > As the dependency is in v4.15-rc1, it can be applied now.
> >
>
> we thought exactly the same thing, therefore we rebased and we re-ran our tests, to discover that something broke in between
> versions.
> I'll be in touch once I have more information, but it's a no go for now.
>
> Thanks,
> Fab
>
>
> [https://www2.renesas.eu/media/email/unicef_2017.jpg]
>
> This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further
> details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
> We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
>
>
>
> Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England &
> Wales under Registered No. 04586709.
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* Re: [PATCH 0/2] of: dynamic: restrict overlay by targets
From: Frank Rowand @ 2017-12-06 11:58 UTC (permalink / raw)
To: Alan Tull
Cc: Moritz Fischer, Rob Herring, Pantelis Antoniou,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
linux-fpga-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CANk1AXQ4HV9YAO_p1wrY66nnWY1n2WnR0JoCbAKU6RfrWqf9sQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/05/17 12:07, Alan Tull wrote:
> On Mon, Dec 4, 2017 at 7:14 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Alan,
>>
>> In the RFC thread "of: Add whitelist", I did not understand the use case and
>> asked you some questions (30 Nov 2017 07:46:36 -0500), that you seem to have
>> overlooked (or my mail server failed to deliver your answer to me). Can you
>> please answer that question so I can better understand this patch set is
>> needed for.
>
> Hi Frank,
>
> Sorry I missed those, I've replied to the original questions now.
Thanks! I have now replied to several comments in that thread, hoping to keep
the conversation in one thread instead of split across two threads.
-Frank
>
> Alan
>
>>
>> Thanks,
>>
>> Frank
>>
>>
>> On 12/04/17 14:13, Alan Tull wrote:
>>> Restrict which nodes are valid targets for a DT overlay.
>>>
>>> Add a flag bit to struct device_node allowing nodes to be marked as
>>> valid target for overlays.
>>>
>>> A driver that is always intended to handle DT overlays can
>>> enable overlays by calling a function for its DT node.
>>>
>>> For individual nodes that need to be opened up for a specific use,
>>> adding the property "overlay-allowed" enables overlays targeting
>>> that node. I'll need to document the DT property, not sure where
>>> specifically. New file bindings/overlay.txt?
>>>
>>> This patchset differs from the RFC:
>>> * Added a flag bit and got rid of the whitelist
>>> * Renamed the functions that enable a node
>>> * Added a DT property
>>>
>>> Alan Tull (2):
>>> of: overlay: add flag enabling overlays and enable fpga-region
>>> overlays
>>> of: dynamic: add overlay-allowed DT property
>>>
>>> drivers/fpga/of-fpga-region.c | 4 ++++
>>> drivers/of/base.c | 4 ++--
>>> drivers/of/dynamic.c | 3 +++
>>> drivers/of/fdt.c | 3 +++
>>> drivers/of/of_private.h | 2 ++
>>> drivers/of/overlay.c | 26 ++++++++++++++++++++++++++
>>> include/linux/of.h | 19 +++++++++++++++++++
>>> 7 files changed, 59 insertions(+), 2 deletions(-)
>>>
>>
>
--
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 0/2] of: Add whitelist
From: Frank Rowand @ 2017-12-06 11:56 UTC (permalink / raw)
To: Alan Tull
Cc: Rob Herring, Pantelis Antoniou, Moritz Fischer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fpga-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CANk1AXQ0L4Uzu_KV9fKeVZZFOPQhQ6uq6y+32=bVXRz+iEngLw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/05/17 11:33, Alan Tull wrote:
> On Thu, Nov 30, 2017 at 6:46 AM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 11/29/17 11:11, Alan Tull wrote:
>>> On Wed, Nov 29, 2017 at 7:31 AM, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>> On Wed, Nov 29, 2017 at 3:20 AM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> On 11/27/17 15:58, Alan Tull wrote:
>>>>>> Here's a proposal for a whitelist to lock down the dynamic device tree.
>>>>>>
>>>>>> For an overlay to be accepted, all of its targets are required to be
>>>>>> on a target node whitelist.
>>>>>>
>>>>>> Currently the only way I have to get on the whitelist is calling a
>>>>>> function to add a node. That works for fpga regions, but I think
>>>>>> other uses will need a way of having adding specific nodes from the
>>>>>> base device tree, such as by adding a property like 'allow-overlay;'
>>>>>> or 'allow-overlay = "okay";' If that is acceptable, I could use some
>>>>>> advice on where that particular code should go.
>>>>>>
>>>>>> Alan
>>>>>>
>>>>>> Alan Tull (2):
>>>>>> of: overlay: add whitelist
>>>>>> fpga: of region: add of-fpga-region to whitelist
>>>>>>
>>>>>> drivers/fpga/of-fpga-region.c | 9 ++++++
>>>>>> drivers/of/overlay.c | 73 +++++++++++++++++++++++++++++++++++++++++++
>>>>>> include/linux/of.h | 12 +++++++
>>>>>> 3 files changed, 94 insertions(+)
>>>>>>
>>>>>
>>>>> The plan was to use connectors to restrict where an overlay could be applied.
>>>>> I would prefer not to have multiple methods for accomplishing the same thing
>>>>> unless there is a compelling reason to do so.
>>>>
>>>> Connector nodes need a mechanism to enable themselves, too. I don't
>>>> think connector nodes are going to solve every usecase.
>>>>
>>>> Rob
>>>
>>> The two methods I'm suggesting are intended to handle different cases.
>>> There will exist some drivers that by their nature will want every
>>> instance to be enabled for overlays, such as fpga regions. The other
>>> case is where drivers could support overlays but that's not the
>>> widespread use for them. So no need to enable every instance of that
>>> driver for overlays.
>>
>> I understand what the paragraph, to this point, means. But I had to
>> read it several times to understand it because the way the concept is
>> phrased clashed with my mental model.
>
> Hi Frank,
>
> I see where my explanation is confusing things. I was talking about
> two methods for marking a node as being a valid target for an overlay
> (use a function or add a DT property). I'll drop the idea of using a
> DT property to enable a node for overlays and only focus on my
> proposal of a function to enable nodes.
>
>>
>> The device node is not an instance of a driver, which is why I was
>> getting confused. (Yes, I do understand that the paragraph is talking
>> about multiple device nodes that are bound to the same driver, but
>> my mental model is tied to the device node, not to the driver.)
>>
>> If each of the device nodes in question is a connector, then each of
>> the nodes will bind to a connector driver, based on the value of the
>> compatible property. (This is of course a theoretical assumption on
>> my part since the connectors are not yet implemented.)
>>
>> If the connector node is an fpga, or an fpga region (I may be getting
>> my terminology wrong here - please correct as needed) then an fpga
>> overlay could be applied to the node.
>
> We're still pre-connector currently, but yes I want to mark FPGA
> regions as being valid targets. Then I can use Pantelis' configfs
> interface to apply overlays while leaving the rest of the DT locked
> down. That's the FPGA use of this patch in the pre-connector era of
> things.
>
>>
>> If I understand what you are saying, there will be some fpga connector
>> nodes for which the usage at a given moment might be programmed to
>> function in a manner that will not be described by an overlay, but
>> at a different moment in time may be programmed in a way that needs
>> to be described by an overlay. So there may be some times that it
>> is valid to apply an overlay to the connector node and times that
>> it is not valid to apply an overlay to the connector node.
>
> I think connectors would likely always be valid targets (but I could
> be wrong) and other nodes would not be valid targets. The DT needs a
> way to mark some nodes as valid targets, currently it doesn't have a
> way of doing that. Every connector driver's probe could use this code
> to mark itself as a valid target.
>
>>
>> Is my understanding correct, or am I still confused?
>
> Hope that helps, sorry for the muddled explanation earlier.
No need to be sorry, I always value what you have to say, and usually
become more educated from reading what you write.
We still seem to be talking at cross purposes. It seems that the model
that you are describing is driver centric. My model is node centric.
Once we figure out what the connector implementation and architecture
are, it might be the case that each connector node has a driver bound
to it, and that driver is able to tell the devicetree core code that
the node that it is bound to is a valid place to apply an overlay.
But I currently think that the core infrastructure code is what
should recognize that a connector node is a valid place to apply
an overlay. It _might_ even be the case the the connector
architecture does not result in a driver being bound to the
connector node.
I would really prefer to get the connector architecture (and
maybe also the implementation) before deciding how to handle
the question of how to determine what nodes overlays can be
appplied to.
>
> Alan
>
>>
>> -Frank
>>
>>> In that case the DT property provides some
>>> granularity, only enabling overlays for specific instances of that
>>> driver, leaving the rest of the DT locked down.>
>>> If we only want one method, I would choose having the DT property only
>>> and not exporting the functions. Users would have to add the property
>>> for every FPGA region but that's not really painful. This would have
>>> the benefit of still keeping the DT locked down unless someone
>>> specifically wanted to enable some regions for overlays for their
>>> particular use.
>>>
>>> Alan
>>>
>>
>
--
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
* [RESEND PATCH 2/4] dt-bindings: display: amlogic,meson-dw-hdmi: Add optional HDMI 5V regulator
From: Neil Armstrong @ 2017-12-06 11:54 UTC (permalink / raw)
To: airlied
Cc: Neil Armstrong, dri-devel, linux-amlogic, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <1512561268-29806-1-git-send-email-narmstrong@baylibre.com>
On reference boards and derivatives, the HDMI Logic is powered by an external
5V regulator.
This regulator was set by the Vendor U-Boot, add optional support for it.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
index 7f040ed..bf4a180 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
@@ -48,6 +48,10 @@ Required properties:
Documentation/devicetree/bindings/reset/reset.txt,
the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy"
+Optional properties:
+- hdmi-supply: Optional phandle to an external 5V regulator to power the HDMI
+ logic, as described in the file ../regulator/regulator.txt
+
Required nodes:
The connections to the HDMI ports are modeled using the OF graph
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH 1/4] dt-bindings: display: amlogic,meson-vpu: Add optional power domain property
From: Neil Armstrong @ 2017-12-06 11:54 UTC (permalink / raw)
To: airlied
Cc: Neil Armstrong, dri-devel, linux-amlogic, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <1512561268-29806-1-git-send-email-narmstrong@baylibre.com>
The Video Processing Unit power domain was setup by the Vendor U-Boot,
add support for an optional Power Domain phandle to setup it from the kernel.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
index 00f74ba..057b813 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
@@ -64,6 +64,10 @@ Required properties:
- reg-names: should contain the names of the previous memory regions
- interrupts: should contain the VENC Vsync interrupt number
+Optional properties:
+- power-domains: Optional phandle to associated power domain as described in
+ the file ../power/power_domain.txt
+
Required nodes:
The connections to the VPU output video ports are modeled using the OF graph
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/6] cpufreq: ARM: sort the Kconfig menu
From: Gregory CLEMENT @ 2017-12-06 11:52 UTC (permalink / raw)
To: Viresh Kumar
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, linux-pm,
Antoine Tenart, Rafael J. Wysocki, Evan Wang, Nadav Haklai,
devicetree, Rob Herring, Neta Zur Hershkovits, Miquèl Raynal,
Victor Gu, Hua Jing, Marcin Wojtas, Wilson Ding, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20171204084124.mchpmw3kta5tddgh@vireshk-mac-ubuntu>
Hi Viresh,
On lun., déc. 04 2017, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 01-12-17, 12:25, Gregory CLEMENT wrote:
>> +config ARM_VEXPRESS_SPC_CPUFREQ
>> + tristate "Versatile Express SPC based CPUfreq driver"
>> + depends on ARM_BIG_LITTLE_CPUFREQ && ARCH_VEXPRESS_SPC
>> + help
>> + This add the CPUfreq driver support for Versatile Express
>> + big.LITTLE platforms using SPC for power management.
>> +
>> +config ARM_SCPI_CPUFREQ
>
> The order of above two must be reversed ?
Right, I will fix it.
Thanks,
Gregory
>
> --
> viresh
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
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 1/6] dt-bindings: marvell: Add documentation for the North Bridge PM on Armada 37xx
From: Gregory CLEMENT @ 2017-12-06 11:51 UTC (permalink / raw)
To: Rob Herring
Cc: Rafael J. Wysocki, Viresh Kumar, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Antoine Tenart,
Miquèl Raynal, Nadav Haklai, Victor Gu, Marcin Wojtas,
Wilson Ding, Hua Jing, Neta Zur Hershkovits, Evan Wang
In-Reply-To: <20171204214706.4sbjgxme3ftmf3l3@rob-hp-laptop>
Hi Rob,
On lun., déc. 04 2017, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Dec 01, 2017 at 12:25:03PM +0100, Gregory CLEMENT wrote:
>> Extend the documentation of the Armada 37xx SoC with the the North
>> Bridge Power Management component.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> ---
>> .../devicetree/bindings/arm/marvell/armada-37xx.txt | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> index 51336e5fc761..7ad9830d9177 100644
>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> @@ -14,3 +14,22 @@ following property before the previous one:
>> Example:
>>
>> compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
>> +
>> +
>> +Power management
>> +----------------
>> +
>> +For power management (particularly DVFS and AVS), the North Bridge
>> +Power Management component is needed:
>> +
>> +Required properties:
>> +- compatible : should contain "marvell,armada-3700-nb-pm", "syscon";
>> +- reg : the register start and length for the North Bridge
>> + Power Management
>> +
>> +Example:
>> +
>> +nb_pm: nb_pm@14000 {
>
> Don't use underscore in node or property names. "syscon" is a better
> choice here.
OK I will change this.
Thanks,
Gregory
>
>> + compatible = "marvell,armada-3700-nb-pm", "syscon";
>> + reg = <0x14000 0x60>;
>> +}
>> --
>> 2.15.0
>>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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 0/2] of: Add whitelist
From: Frank Rowand @ 2017-12-06 11:47 UTC (permalink / raw)
To: Alan Tull
Cc: Rob Herring, Pantelis Antoniou, Moritz Fischer,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fpga
In-Reply-To: <CANk1AXSAdRT8WWg+xqCWGNYwO=4ke-74ETs+HNObcswEBmKz4g@mail.gmail.com>
On 12/05/17 11:55, Alan Tull wrote:
> On Thu, Nov 30, 2017 at 6:18 AM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 11/29/17 08:31, Rob Herring wrote:
>>> On Wed, Nov 29, 2017 at 3:20 AM, Frank Rowand <frowand.list@gmail.com> wrote:
>>>> On 11/27/17 15:58, Alan Tull wrote:
>>>>> Here's a proposal for a whitelist to lock down the dynamic device tree.
>>>>>
>>>>> For an overlay to be accepted, all of its targets are required to be
>>>>> on a target node whitelist.
>>>>>
>>>>> Currently the only way I have to get on the whitelist is calling a
>>>>> function to add a node. That works for fpga regions, but I think
>>>>> other uses will need a way of having adding specific nodes from the
>>>>> base device tree, such as by adding a property like 'allow-overlay;'
>>>>> or 'allow-overlay = "okay";' If that is acceptable, I could use some
>>>>> advice on where that particular code should go.
>>>>>
>>>>> Alan
>>>>>
>>>>> Alan Tull (2):
>>>>> of: overlay: add whitelist
>>>>> fpga: of region: add of-fpga-region to whitelist
>>>>>
>>>>> drivers/fpga/of-fpga-region.c | 9 ++++++
>>>>> drivers/of/overlay.c | 73 +++++++++++++++++++++++++++++++++++++++++++
>>>>> include/linux/of.h | 12 +++++++
>>>>> 3 files changed, 94 insertions(+)
>>>>>
>>>>
>>>> The plan was to use connectors to restrict where an overlay could be applied.
>>>> I would prefer not to have multiple methods for accomplishing the same thing
>>>> unless there is a compelling reason to do so.
>>>
>>> Connector nodes need a mechanism to enable themselves, too. I don't
>>> think connector nodes are going to solve every usecase.
>>>
>>> Rob
>>>
>>
>> The overlay code related to connectors does not exist yet, so my comment
>> is going to be theoretical.
>>
>> I would expect the overlay code to check that the target of the overlay
>> fragment is a connector node, so there is no need to explicitly "enable"
>> applying an overlay to a connector node.
>
> This will depend on how connectors are implemented. My proposal in v1
> is that device nodes can have a flag bit. If its not set, then an
> overlay that contains fragments that target that node can't be
> applied. There's probably other ways a connector node could be marked
> as different from other nodes, but a flag bit seems simple. The
> advantage to this scheme is that it gives me something I can use while
> connectors don't exist yet and it will still will be useful later for
> the implementation of connectors (giving connector drivers a way of
> marking their device nodes as valid targets).
I think it is premature to add this code to the kernel when we don't
have an agreed upon architecture for what we are trying to achieve.
>
>>
>> -Frank
>
^ permalink raw reply
* Re: [RFC 0/2] of: Add whitelist
From: Frank Rowand @ 2017-12-06 11:44 UTC (permalink / raw)
To: Rob Herring
Cc: Alan Tull, Rob Herring, Pantelis Antoniou, Moritz Fischer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List, linux-fpga-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CABGGisyiG3mV9s+ksgNFVgoOk=dJrFn4PGj6Ny-O7=o9kmpRTw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/30/17 09:39, Rob Herring wrote:
> On Wed, Nov 29, 2017 at 4:47 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 11/29/17 04:20, Frank Rowand wrote:
>>> On 11/27/17 15:58, Alan Tull wrote:
>>>> Here's a proposal for a whitelist to lock down the dynamic device tree.
>>>>
>>>> For an overlay to be accepted, all of its targets are required to be
>>>> on a target node whitelist.
>>>>
>>>> Currently the only way I have to get on the whitelist is calling a
>>>> function to add a node. That works for fpga regions, but I think
>>>> other uses will need a way of having adding specific nodes from the
>>>> base device tree, such as by adding a property like 'allow-overlay;'
>>>> or 'allow-overlay = "okay";' If that is acceptable, I could use some
>>>> advice on where that particular code should go.
>>>>
>>>> Alan
>>>>
>>>> Alan Tull (2):
>>>> of: overlay: add whitelist
>>>> fpga: of region: add of-fpga-region to whitelist
>>>>
>>>> drivers/fpga/of-fpga-region.c | 9 ++++++
>>>> drivers/of/overlay.c | 73 +++++++++++++++++++++++++++++++++++++++++++
>>>> include/linux/of.h | 12 +++++++
>>>> 3 files changed, 94 insertions(+)
>>>>
>>>
>>> The plan was to use connectors to restrict where an overlay could be applied.
>>> I would prefer not to have multiple methods for accomplishing the same thing
>>> unless there is a compelling reason to do so.
>>
>> Going back one level in my thinking, I don't think that having a driver mark
>> a node as a location where an overlay fragment can be applied is serving a
>> useful purpose. Any driver, including any driver loaded as a module,
>> could mark a node as ok. I don't see how this is providing any meaningful
>> restriction on where an overlay fragment can be applied.
>
> It serves to separate the setting of which nodes overlays can be
> applied to and the mechanism to apply them (checking permissions). The
> former can't be centralized
My expectation is that determining which nodes overlays can be applied
to can and _should_ be centralized, at least to begin with. If we
loosen the restrictions on valid overlay application nodes then we
_might_ find that we have to provide additional non-centralized permission
granting.
I think that the core devicetree code is the place (for initial implementation)
that determining which nodes an overlay can be applied to. My expectation
is that it will be implicitly obvious to the core devicetree code which
nodes are connector nodes. Given that there have been several different
proposals for connector implementation, my expectation may be completely
wrong. So I am sure I will revisit my expectations the actual
implementation of connectors arrives.
Since the architecture and implementation of connectors is still so
uncertain, I think it is premature to accept the changes proposed in
the patch set, and the next patch set that has been proposed in
response to the conversation in this thread.
> and the latter can be. For example,
> something in the kernel enables overlays on a node or nodes, then the
> overlay is applied with configfs interface and no board specific code
> involved.
I agree that the permission checking should not need to involve board
specific code.
> My concern is not whether any kernel component can enable applying of
> overlays, but userspace. If it is a kernel component, then it is
> explicit. And an OOT kernel module doesn't count because there's no
> ABI guarantee there.
>
> I agree that this patch series alone is not all that useful with only
> in kernel users. It is only really interesting when we have a
> userspace interface. However, an implementation with a flag bit is so
> little code, I'm fine taking it now and not having to update all in
> kernel users when adding a userspace interface.
I think the concept of an API called by a driver, instead of the
devicetree core code determining which nodes an overlay can be
applied to is premature, since there is no direct need for it,
and given that it is little code it can easily be added when it
is needed, and we better understand how it will be used.
>
> Rob
>
--
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] ARM: dts: colibri/apalis: use correct compatible for RTC
From: Fabio Estevam @ 2017-12-06 11:41 UTC (permalink / raw)
To: Stefan Agner
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Sanchayan Maity, Marcel Ziswiler
In-Reply-To: <20171206102929.4755-1-stefan-XLVq0VzYD2Y@public.gmane.org>
On Wed, Dec 6, 2017 at 8:29 AM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
> All Toradex Carrier Boards use a st,m41t0 compatible RTC. Compared
> to a st,m41t00 this RTC has also an oscillator fail bit which allows
> to detect when the RTC lost track of time.
>
> Cc: Sanchayan Maity <maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Marcel Ziswiler <marcel.ziswiler-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
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 3/5] PCI: cadence: Add host driver for Cadence PCIe controller
From: Lorenzo Pieralisi @ 2017-12-06 11:32 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Cyrille Pitchen, Bjorn Helgaas, kishon-l0cyMroinI0, linux-pci,
adouglas-vna1KIf7WgpBDgjK7y7TUQ, Scott Telford,
dgary-vna1KIf7WgpBDgjK7y7TUQ, kgopi-vna1KIf7WgpBDgjK7y7TUQ,
eandrews-vna1KIf7WgpBDgjK7y7TUQ, Thomas Petazzoni,
sureshp-vna1KIf7WgpBDgjK7y7TUQ, nsekhar-l0cyMroinI0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAKv+Gu_1XZmsKJ_7ay7D74xSAhDW0y++7-CC3YfG7LOUcNZSqA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Dec 04, 2017 at 06:49:12PM +0000, Ard Biesheuvel wrote:
[...]
> >> >> +static int cdns_pcie_host_init_root_port(struct cdns_pcie_rc *rc)
> >> >> +{
> >> >> + const struct cdns_pcie_rc_data *data = rc->data;
> >> >> + struct cdns_pcie *pcie = &rc->pcie;
> >> >> + u8 pbn, sbn, subn;
> >> >> + u32 value, ctrl;
> >> >> +
> >> >> + /*
> >> >> + * Set the root complex BAR configuration register:
> >> >> + * - disable both BAR0 and BAR1.
> >> >> + * - enable Prefetchable Memory Base and Limit registers in type 1
> >> >> + * config space (64 bits).
> >> >> + * - enable IO Base and Limit registers in type 1 config
> >> >> + * space (32 bits).
> >> >> + */
> >> >> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_DISABLED;
> >> >> + value = CDNS_PCIE_LM_RC_BAR_CFG_BAR0_CTRL(ctrl) |
> >> >> + CDNS_PCIE_LM_RC_BAR_CFG_BAR1_CTRL(ctrl) |
> >> >> + CDNS_PCIE_LM_RC_BAR_CFG_PREFETCH_MEM_ENABLE |
> >> >> + CDNS_PCIE_LM_RC_BAR_CFG_PREFETCH_MEM_64BITS |
> >> >> + CDNS_PCIE_LM_RC_BAR_CFG_IO_ENABLE |
> >> >> + CDNS_PCIE_LM_RC_BAR_CFG_IO_32BITS;
> >> >> + cdns_pcie_writel(pcie, CDNS_PCIE_LM_RC_BAR_CFG, value);
> >> >> +
> >> >> + /* Set root port configuration space */
> >> >> + if (data->vendor_id != 0xffff)
> >> >> + cdns_pcie_rp_writew(pcie, PCI_VENDOR_ID, data->vendor_id);
> >> >> + if (data->device_id != 0xffff)
> >> >> + cdns_pcie_rp_writew(pcie, PCI_DEVICE_ID, data->device_id);
> >> >> +
> >> >> + cdns_pcie_rp_writeb(pcie, PCI_CLASS_REVISION, 0);
> >> >> + cdns_pcie_rp_writeb(pcie, PCI_CLASS_PROG, 0);
> >> >> + cdns_pcie_rp_writew(pcie, PCI_CLASS_DEVICE, PCI_CLASS_BRIDGE_PCI);
> >> >> +
> >> >> + pbn = rc->bus_range->start;
> >> >> + sbn = pbn + 1; /* Single root port. */
> >> >> + subn = rc->bus_range->end;
> >> >> + cdns_pcie_rp_writeb(pcie, PCI_PRIMARY_BUS, pbn);
> >> >> + cdns_pcie_rp_writeb(pcie, PCI_SECONDARY_BUS, sbn);
> >> >> + cdns_pcie_rp_writeb(pcie, PCI_SUBORDINATE_BUS, subn);
> >> >
> >> > Again - I do not have the datasheet for this device therefore I would
> >> > kindly ask you how this works; it seems to me that what you are doing
> >> > here is done through normal configuration cycles in an ECAM compliant
> >> > system to program the RP PRIMARY/SECONDARY/SUBORDINATE bus - I would
> >> > like to understand why this code is needed.
> >> >
> >>
> >> I will test without those lines to test whether I can remove them.
> >>
> >> At first, the PCIe controller was tested by Cadence team: there was code
> >> in their bootloader to initialize the hardware (building the AXI <-> PCIe
> >> mappings, ...): the bootloader used to set the primary, secondary and
> >> subordinate bus numbers in the root port PCI config space.
> >>
> >> Also there was a hardware trick to redirect accesses of the lowest
> >> addresses in the AXI bus to the APB bus so the PCI configuration space of
> >> the root port could have been accessed from the AXI bus too.
> >>
> >> The AXI <-> PCIe mapping being done by the bootloader and the root port
> >> config space being accessible from the AXI bus, it was possible to use
> >> the pci-host-generic driver.
> >
> > That's what I was getting at. Ard (CC'ed) implemented a firmware set-up
> > (even though it was for a different IP but maybe it applies here) that
> > allows the kernel to use the pci-host-generic driver to initialize the
> > PCI controller:
> >
> > https://marc.info/?l=linux-pci&m=150360022626351&w=2
> >
> > I want to understand if there is an IP initialization sequence whereby
> > this IP can be made to work in an ECAM compliant way and therefore
> > reuse (most of) the pci-host-generic driver code.
> >
>
> I think the Synopsys case is probably very similar. There are some
> registers that look like the config space of a root port, but in
> reality, every memory access that hits a live host bridge window is
> forwarded onto the link, regardless of the values of the bridge BARs.
> That is why in the quoted case, we can get away with ignoring the root
> port altogether, rather than jumping through hoops to make the IP
> block's PCI config space registers appear at B/D/F 0/0/0, while still
> having to filter type 0 config TLPs going onto the link (which is
> arguably the job of the root port to begin with)
>
> So if this IP does implement a proper root port (i.e., one where the
> bridge BARs are actually taken into account, and where type 0 config
> TLPs are in fact filtered), I strongly recommend mapping its config
> space registers in an ECAM compliant matter, which implies no
> accessors in the OS.
>
> However, given the observation above, this IP does not appear to
> filter type 0 config TLPs to devfn > 0 downstream of the root port
> either.
Unfortunately that matches my understanding too, let's wait for
Cyrille's reply on my query.
> >> However, the hardware trick won't be included in the final design since
> >> Cadence now wants to perform all PCI configuration space accesses through
> >> a small 4KB window at a fixed address on the AXI bus.
> >
> > I would like to understand what the HW "trick" (if you can disclose it)
> > was, because if there is a chance to reuse the pci-host-generic driver
> > for this IP I want to take it (yes it may entail some firmware set-up in
> > the bootloader) - was it a HW trick or a specific IP SW configuration ?
> >
> >> Also, we now want all initialisations to be done by the linux driver
> >> instead of the bootloader.
> >
> > That's a choice, I do not necessarily agree with it and I think we
> > should aim for more standardization on the PCI host bridge set-up
> > at firmware->kernel handover on DT platforms.
> >
>
> Well, for one, it means this IP will never be supported by ACPI, which
> seems like a huge downside to me.
Yes it is - that's exactly where my comments were heading.
Thanks,
Lorenzo
--
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 2/3] arm64: dts: rockchip: add usb3-phy phandle for dwc3.
From: Enric Balletbo i Serra @ 2017-12-06 11:27 UTC (permalink / raw)
To: Heiko Stübner
Cc: devicetree, linux-rockchip, linux-kernel, Rob Herring, dianders,
Chanwoo Choi, MyungJoo Ham, groeck, briannorris, Lee Jones,
linux-arm-kernel
In-Reply-To: <1756641.7q7fHBPi13@diego>
Hi Heiko,
On 06/12/17 12:20, Heiko Stübner wrote:
> Am Mittwoch, 6. Dezember 2017, 12:10:07 CET schrieb Enric Balletbo i Serra:
>> This patch adds the usb3-phy for both of the two dwc3 controllers on
>> rk3399.
>
> This patch adds quite a bit more than the phy phandles though.
>
> The powerdomain addition should definitly be a separate patch
> and the usb3-grf clock as well.
>
Ok, I'll split these parts and send in a separate patch in v2. Thanks for the
feedback.
Enric
>
> Heiko
>
>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 28 ++++++++++++++++++++--------
>> 1 file changed, 20 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index 17e5e1a..c18ff88 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -397,9 +397,11 @@
>> #size-cells = <2>;
>> ranges;
>> clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
>> - <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
>> + <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
>> + <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
>> clock-names = "ref_clk", "suspend_clk",
>> - "bus_clk", "grf_clk";
>> + "bus_clk", "aclk_usb3_rksoc_axi_perf",
>> + "aclk_usb3", "grf_clk";
>> status = "disabled";
>>
>> usbdrd_dwc3_0: dwc3 {
>> @@ -407,14 +409,15 @@
>> reg = <0x0 0xfe800000 0x0 0x100000>;
>> interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
>> dr_mode = "otg";
>> - phys = <&u2phy0_otg>;
>> - phy-names = "usb2-phy";
>> + phys = <&u2phy0_otg>, <&tcphy0_usb3>;
>> + phy-names = "usb2-phy", "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,dis-tx-ipgap-linecheck-quirk;
>> + power-domains = <&power RK3399_PD_USB3>;
>> status = "disabled";
>> };
>> };
>> @@ -425,9 +428,11 @@
>> #size-cells = <2>;
>> ranges;
>> clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
>> - <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
>> + <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
>> + <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
>> clock-names = "ref_clk", "suspend_clk",
>> - "bus_clk", "grf_clk";
>> + "bus_clk", "aclk_usb3_rksoc_axi_perf",
>> + "aclk_usb3", "grf_clk";
>> status = "disabled";
>>
>> usbdrd_dwc3_1: dwc3 {
>> @@ -435,14 +440,15 @@
>> reg = <0x0 0xfe900000 0x0 0x100000>;
>> interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
>> dr_mode = "otg";
>> - phys = <&u2phy1_otg>;
>> - phy-names = "usb2-phy";
>> + phys = <&u2phy1_otg>, <&tcphy1_usb3>;
>> + phy-names = "usb2-phy", "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,dis-tx-ipgap-linecheck-quirk;
>> + power-domains = <&power RK3399_PD_USB3>;
>> status = "disabled";
>> };
>> };
>> @@ -991,6 +997,12 @@
>> clocks = <&cru HCLK_SDIO>;
>> pm_qos = <&qos_sdioaudio>;
>> };
>> + 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>;
>
>
_______________________________________________
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 1/8] ARM: dts: r8a7745: Add APMU node and second CPU core
From: Fabrizio Castro @ 2017-12-06 11:21 UTC (permalink / raw)
To: Geert Uytterhoeven, Simon Horman
Cc: Chris Paterson, Rob Herring, Mark Rutland, Magnus Damm,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux-Renesas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Geert Uytterhoeven
In-Reply-To: <CAMuHMdUuF4kwUiUYCbSew3W0Pa2CfRdCijefbOO1ZYAbnyG3KA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello Geert, Simon,
>
> As the dependency is in v4.15-rc1, it can be applied now.
>
we thought exactly the same thing, therefore we rebased and we re-ran our tests, to discover that something broke in between versions.
I'll be in touch once I have more information, but it's a no go for now.
Thanks,
Fab
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ 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