* [PATCH 1/4] ASoC: codecs: tas5720: add basic support for TAS5722 devices
From: Andrew F. Davis @ 2017-12-11 19:01 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland
Cc: alsa-devel, devicetree, linux-kernel, Andrew F . Davis
From: Andreas Dannenberg <dannenberg@ti.com>
The TI TAS5722 digital amplifier is very similar to the TAS5720 from an
overall and register map perspective. Therefore the existing driver can be
extended easily to support this additional device. This commit allows
TAS5722 devices to be used in a "subset" type of fashion, without exposing
any of the additional features they offer.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
.../devicetree/bindings/sound/tas5720.txt | 4 ++-
sound/soc/codecs/tas5720.c | 38 ++++++++++++++++++----
sound/soc/codecs/tas5720.h | 1 +
3 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/tas5720.txt b/Documentation/devicetree/bindings/sound/tas5720.txt
index 40d94f82beb3..7481653fe8e3 100644
--- a/Documentation/devicetree/bindings/sound/tas5720.txt
+++ b/Documentation/devicetree/bindings/sound/tas5720.txt
@@ -6,10 +6,12 @@ audio playback. For more product information please see the links below:
http://www.ti.com/product/TAS5720L
http://www.ti.com/product/TAS5720M
+http://www.ti.com/product/TAS5722L
Required properties:
-- compatible : "ti,tas5720"
+- compatible : "ti,tas5720",
+ "ti,tas5722"
- reg : I2C slave address
- dvdd-supply : phandle to a 3.3-V supply for the digital circuitry
- pvdd-supply : phandle to a supply used for the Class-D amp and the analog
diff --git a/sound/soc/codecs/tas5720.c b/sound/soc/codecs/tas5720.c
index a736a2a6976c..5def54d1336d 100644
--- a/sound/soc/codecs/tas5720.c
+++ b/sound/soc/codecs/tas5720.c
@@ -36,6 +36,11 @@
/* Define how often to check (and clear) the fault status register (in ms) */
#define TAS5720_FAULT_CHECK_INTERVAL 200
+enum tas572x_type {
+ TAS5720,
+ TAS5722,
+};
+
static const char * const tas5720_supply_names[] = {
"dvdd", /* Digital power supply. Connect to 3.3-V supply. */
"pvdd", /* Class-D amp and analog power supply (connected). */
@@ -47,6 +52,7 @@ struct tas5720_data {
struct snd_soc_codec *codec;
struct regmap *regmap;
struct i2c_client *tas5720_client;
+ enum tas572x_type devtype;
struct regulator_bulk_data supplies[TAS5720_NUM_SUPPLIES];
struct delayed_work fault_check_work;
unsigned int last_fault;
@@ -264,7 +270,7 @@ static void tas5720_fault_check_work(struct work_struct *work)
static int tas5720_codec_probe(struct snd_soc_codec *codec)
{
struct tas5720_data *tas5720 = snd_soc_codec_get_drvdata(codec);
- unsigned int device_id;
+ unsigned int device_id, expected_device_id;
int ret;
tas5720->codec = codec;
@@ -276,6 +282,11 @@ static int tas5720_codec_probe(struct snd_soc_codec *codec)
return ret;
}
+ /*
+ * Take a liberal approach to checking the device ID to allow the
+ * driver to be used even if the device ID does not match, however
+ * issue a warning if there is a mismatch.
+ */
ret = regmap_read(tas5720->regmap, TAS5720_DEVICE_ID_REG, &device_id);
if (ret < 0) {
dev_err(codec->dev, "failed to read device ID register: %d\n",
@@ -283,13 +294,22 @@ static int tas5720_codec_probe(struct snd_soc_codec *codec)
goto probe_fail;
}
- if (device_id != TAS5720_DEVICE_ID) {
- dev_err(codec->dev, "wrong device ID. expected: %u read: %u\n",
- TAS5720_DEVICE_ID, device_id);
- ret = -ENODEV;
- goto probe_fail;
+ switch (tas5720->devtype) {
+ case TAS5720:
+ expected_device_id = TAS5720_DEVICE_ID;
+ break;
+ case TAS5722:
+ expected_device_id = TAS5722_DEVICE_ID;
+ break;
+ default:
+ dev_err(codec->dev, "unexpected private driver data\n");
+ return -EINVAL;
}
+ if (device_id != expected_device_id)
+ dev_warn(codec->dev, "wrong device ID. expected: %u read: %u\n",
+ expected_device_id, device_id);
+
/* Set device to mute */
ret = snd_soc_update_bits(codec, TAS5720_DIGITAL_CTRL2_REG,
TAS5720_MUTE, TAS5720_MUTE);
@@ -552,6 +572,8 @@ static int tas5720_probe(struct i2c_client *client,
return -ENOMEM;
data->tas5720_client = client;
+ data->devtype = id->driver_data;
+
data->regmap = devm_regmap_init_i2c(client, &tas5720_regmap_config);
if (IS_ERR(data->regmap)) {
ret = PTR_ERR(data->regmap);
@@ -592,7 +614,8 @@ static int tas5720_remove(struct i2c_client *client)
}
static const struct i2c_device_id tas5720_id[] = {
- { "tas5720", 0 },
+ { "tas5720", TAS5720 },
+ { "tas5722", TAS5722 },
{ }
};
MODULE_DEVICE_TABLE(i2c, tas5720_id);
@@ -600,6 +623,7 @@ MODULE_DEVICE_TABLE(i2c, tas5720_id);
#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id tas5720_of_match[] = {
{ .compatible = "ti,tas5720", },
+ { .compatible = "ti,tas5722", },
{ },
};
MODULE_DEVICE_TABLE(of, tas5720_of_match);
diff --git a/sound/soc/codecs/tas5720.h b/sound/soc/codecs/tas5720.h
index 3d077c779b12..bef802afcc69 100644
--- a/sound/soc/codecs/tas5720.h
+++ b/sound/soc/codecs/tas5720.h
@@ -32,6 +32,7 @@
/* TAS5720_DEVICE_ID_REG */
#define TAS5720_DEVICE_ID 0x01
+#define TAS5722_DEVICE_ID 0x12
/* TAS5720_POWER_CTRL_REG */
#define TAS5720_DIG_CLIP_MASK GENMASK(7, 2)
--
2.15.0
^ permalink raw reply related
* Re: [PATCH v3 3/3] ARM: dts: exynos: Add nodes for True Random Number Generator
From: Krzysztof Kozlowski @ 2017-12-11 18:49 UTC (permalink / raw)
To: Łukasz Stelmach
Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Rob Herring,
Matt Mackall, Herbert Xu, Kukjin Kim, devicetree, linux-crypto,
linux-samsung-soc, linux-kernel, Marek Szyprowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20171204125351.26805-4-l.stelmach@samsung.com>
On Mon, Dec 04, 2017 at 01:53:51PM +0100, Łukasz Stelmach wrote:
> Add nodes for the True Random Number Generator found in Samsung Exynos
> 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
> ---
> arch/arm/boot/dts/exynos5.dtsi | 5 +++++
> arch/arm/boot/dts/exynos5250.dtsi | 5 +++++
> arch/arm/boot/dts/exynos5410.dtsi | 5 +++++
> arch/arm/boot/dts/exynos5420.dtsi | 5 +++++
> 4 files changed, 20 insertions(+)
>
Unfortunately the same story as with your PRNG patch - does not apply on
top of my next/dt (after taking PRNG). Also did not apply on v4.15-rc1 +
PRNG.
Could you rebase on my next/dt?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC] irqchip: add support for LS1021A external interrupt lines
From: Marc Zyngier @ 2017-12-11 18:29 UTC (permalink / raw)
To: Rasmus Villemoes, Thomas Gleixner, Jason Cooper, Rob Herring,
Mark Rutland
Cc: Alexander Stein, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <563e0aaa-faf9-ae6a-ccd4-2aa89d7e457b-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
On 11/12/17 09:30, Rasmus Villemoes wrote:
> On 2017-12-08 17:02, Marc Zyngier wrote:
[...]
>> Overall, it is a bit annoying that you just copied the driver altogether
>> instead of trying to allow the common stuff to be shared between
>> drivers. Most of this is just boilerplate code...
>
> Yes, it did annoy me as well. However, the real meat of this is which
> bits of which register to poke to support a negative polarity irq, and
> there doesn't seem to be a good way to express that in DT. The register
> offset and the mapping from external irq# to the GIC one is reasonably
> easy (and would thus get rid of my NIRQ and INTPCR macros), but
> describing the mapping from IRQ# to the bit that needs to be set (or
> cleared) seems much harder. I cannot generalize from one example, so
> lacking documentation for any other Layerscape SOC, whatever I might
> come up with might not actually be useful for other hardware, making it
> rather pointless. But if you have any suggestions for how the DT
> bindings might look, I'm all ears.
You could have a list of <bit irq> pairs defining the mapping, for
example. But I'd encourage you to get in touch with the Freescale/NXP
folks and find out how this HW works. get_maintainers.pl gives me this:
Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Tang Yuantian <Yuantian.Tang-3arQi8VN3Tc@public.gmane.org>
Hou Zhiqiang <Zhiqiang.Hou-3arQi8VN3Tc@public.gmane.org>
Madalin Bucur <madalin.bucur-3arQi8VN3Tc@public.gmane.org>
Minghuan Lian <Minghuan.Lian-3arQi8VN3Tc@public.gmane.org>
Yuantian Tang <andy.tang-3arQi8VN3Tc@public.gmane.org>
Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
"Horia Geantă" <horia.geanta-3arQi8VN3Tc@public.gmane.org>
I suggest you spam them and find out.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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: [PATCHv2 00/20] ARM: dts: add omap clkctrl support
From: Tony Lindgren @ 2017-12-11 18:29 UTC (permalink / raw)
To: Tero Kristo
Cc: bcousson-rdvid1DuHRBWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512746251-20123-1-git-send-email-t-kristo-l0cyMroinI0@public.gmane.org>
* Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org> [171208 07:20]:
> Hi,
>
> Just reposting v2 of the relevant patches. The only change in this
> version is the conversion of clkctrl clock handles to use the
> dt-binding macros instead of hardcoded magic values. The contents
> of the compiled .dtb files are completely unchanged in this.
>
> e.g. clocks = <&l4per_clkctrl 0 0> => <&l4per_clkctrl OMAP4_UART3_CLKCTRL 0>
Thanks applying all 20 picked from the two series into omap-for-v4.16/dt-clk.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v9 2/2] leds: lm3692x: Introduce LM3692x dual string driver
From: Dan Murphy @ 2017-12-11 18:26 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Dan Murphy
In-Reply-To: <20171211182659.21533-1-dmurphy-l0cyMroinI0@public.gmane.org>
Introducing the LM3692x Dual-String white LED driver.
Data sheet is located
http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
---
v9 - Change the no DT label case to pull the device name from the i2c_id struct
so that the device name can be part of the sysfs node - https://patchwork.kernel.org/patch/10093759/
v8 - No changes
v7 - Reverted back to creating the LED label within the driver -
https://patchwork.kernel.org/patch/10087473/
v6 - Use new LED API to compose LED label as opposed to creating it. -
https://patchwork.kernel.org/patch/10085565/
v5 - Added OF dependency in Kconfig, added extra fault flag read to ensure that
if a fault exists and it is not a artifact, fixed LED class label to be derived
from either the DT child "label" node or create a label based on
parent_node_name:led color:trigger, removed ifdef for CONFIG_OF and removed
of_match_ptr - https://patchwork.kernel.org/patch/10081073/
v4 - Converted to devm led class register, changed MODULE_LICENSE to GPL v2,
set the led name based on child node name or label entry, removed fault and
returned read_buf for fault checking, added mutex_destroy to remove function,
and removed LED_FULL - https://patchwork.kernel.org/patch/10060109/
v3 - Add missing Makefile and Kconfig from v1 and v2 - https://patchwork.kernel.org/patch/10060075/
v2 - Added data sheet link, fixed linuxdoc format, returned on failure in init
routine, return on fault_check failure, updated brightness calculation and
fixed capitalization issue - https://patchwork.kernel.org/patch/10056675/
drivers/leds/Kconfig | 7 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3692x.c | 393 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 401 insertions(+)
create mode 100644 drivers/leds/leds-lm3692x.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 318a28fd58fe..1d215b39cefd 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -137,6 +137,13 @@ config LEDS_LM3642
converter plus 1.5A constant current driver for a high-current
white LED.
+config LEDS_LM3692X
+ tristate "LED support for LM3692x Chips"
+ depends on LEDS_CLASS && I2C && OF
+ select REGMAP_I2C
+ help
+ This option enables support for the TI LM3692x family
+ of white LED string drivers used for backlighting.
config LEDS_LOCOMO
tristate "LED Support for Locomo device"
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index a2a6b5a4f86d..987884a5b9a5 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_LEDS_PM8058) += leds-pm8058.o
obj-$(CONFIG_LEDS_MLXCPLD) += leds-mlxcpld.o
obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
+obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
new file mode 100644
index 000000000000..7077f9459bce
--- /dev/null
+++ b/drivers/leds/leds-lm3692x.c
@@ -0,0 +1,393 @@
+/*
+ * TI lm3692x LED Driver
+ *
+ * Copyright (C) 2017 Texas Instruments
+ *
+ * Author: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * Data sheet is located
+ * http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
+ */
+
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/leds.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/slab.h>
+#include <uapi/linux/uleds.h>
+
+#define LM3692X_REV 0x0
+#define LM3692X_RESET 0x1
+#define LM3692X_EN 0x10
+#define LM3692X_BRT_CTRL 0x11
+#define LM3692X_PWM_CTRL 0x12
+#define LM3692X_BOOST_CTRL 0x13
+#define LM3692X_AUTO_FREQ_HI 0x15
+#define LM3692X_AUTO_FREQ_LO 0x16
+#define LM3692X_BL_ADJ_THRESH 0x17
+#define LM3692X_BRT_LSB 0x18
+#define LM3692X_BRT_MSB 0x19
+#define LM3692X_FAULT_CTRL 0x1e
+#define LM3692X_FAULT_FLAGS 0x1f
+
+#define LM3692X_SW_RESET BIT(0)
+#define LM3692X_DEVICE_EN BIT(0)
+#define LM3692X_LED1_EN BIT(1)
+#define LM3692X_LED2_EN BIT(2)
+
+/* Brightness Control Bits */
+#define LM3692X_BL_ADJ_POL BIT(0)
+#define LM3692X_RAMP_RATE_125us 0x00
+#define LM3692X_RAMP_RATE_250us BIT(1)
+#define LM3692X_RAMP_RATE_500us BIT(2)
+#define LM3692X_RAMP_RATE_1ms (BIT(1) | BIT(2))
+#define LM3692X_RAMP_RATE_2ms BIT(3)
+#define LM3692X_RAMP_RATE_4ms (BIT(3) | BIT(1))
+#define LM3692X_RAMP_RATE_8ms (BIT(2) | BIT(3))
+#define LM3692X_RAMP_RATE_16ms (BIT(1) | BIT(2) | BIT(3))
+#define LM3692X_RAMP_EN BIT(4)
+#define LM3692X_BRHT_MODE_REG 0x00
+#define LM3692X_BRHT_MODE_PWM BIT(5)
+#define LM3692X_BRHT_MODE_MULTI_RAMP BIT(6)
+#define LM3692X_BRHT_MODE_RAMP_MULTI (BIT(5) | BIT(6))
+#define LM3692X_MAP_MODE_EXP BIT(7)
+
+/* PWM Register Bits */
+#define LM3692X_PWM_FILTER_100 BIT(0)
+#define LM3692X_PWM_FILTER_150 BIT(1)
+#define LM3692X_PWM_FILTER_200 (BIT(0) | BIT(1))
+#define LM3692X_PWM_HYSTER_1LSB BIT(2)
+#define LM3692X_PWM_HYSTER_2LSB BIT(3)
+#define LM3692X_PWM_HYSTER_3LSB (BIT(3) | BIT(2))
+#define LM3692X_PWM_HYSTER_4LSB BIT(4)
+#define LM3692X_PWM_HYSTER_5LSB (BIT(4) | BIT(2))
+#define LM3692X_PWM_HYSTER_6LSB (BIT(4) | BIT(3))
+#define LM3692X_PWM_POLARITY BIT(5)
+#define LM3692X_PWM_SAMP_4MHZ BIT(6)
+#define LM3692X_PWM_SAMP_24MHZ BIT(7)
+
+/* Boost Control Bits */
+#define LM3692X_OCP_PROT_1A BIT(0)
+#define LM3692X_OCP_PROT_1_25A BIT(1)
+#define LM3692X_OCP_PROT_1_5A (BIT(0) | BIT(1))
+#define LM3692X_OVP_21V BIT(2)
+#define LM3692X_OVP_25V BIT(3)
+#define LM3692X_OVP_29V (BIT(2) | BIT(3))
+#define LM3692X_MIN_IND_22UH BIT(4)
+#define LM3692X_BOOST_SW_1MHZ BIT(5)
+#define LM3692X_BOOST_SW_NO_SHIFT BIT(6)
+
+/* Fault Control Bits */
+#define LM3692X_FAULT_CTRL_OVP BIT(0)
+#define LM3692X_FAULT_CTRL_OCP BIT(1)
+#define LM3692X_FAULT_CTRL_TSD BIT(2)
+#define LM3692X_FAULT_CTRL_OPEN BIT(3)
+
+/* Fault Flag Bits */
+#define LM3692X_FAULT_FLAG_OVP BIT(0)
+#define LM3692X_FAULT_FLAG_OCP BIT(1)
+#define LM3692X_FAULT_FLAG_TSD BIT(2)
+#define LM3692X_FAULT_FLAG_SHRT BIT(3)
+#define LM3692X_FAULT_FLAG_OPEN BIT(4)
+
+/**
+ * struct lm3692x_led -
+ * @lock - Lock for reading/writing the device
+ * @client - Pointer to the I2C client
+ * @led_dev - LED class device pointer
+ * @regmap - Devices register map
+ * @enable_gpio - VDDIO/EN gpio to enable communication interface
+ * @regulator - LED supply regulator pointer
+ * @label - LED label
+ */
+struct lm3692x_led {
+ struct mutex lock;
+ struct i2c_client *client;
+ struct led_classdev led_dev;
+ struct regmap *regmap;
+ struct gpio_desc *enable_gpio;
+ struct regulator *regulator;
+ char label[LED_MAX_NAME_SIZE];
+};
+
+static const struct reg_default lm3692x_reg_defs[] = {
+ {LM3692X_EN, 0xf},
+ {LM3692X_BRT_CTRL, 0x61},
+ {LM3692X_PWM_CTRL, 0x73},
+ {LM3692X_BOOST_CTRL, 0x6f},
+ {LM3692X_AUTO_FREQ_HI, 0x0},
+ {LM3692X_AUTO_FREQ_LO, 0x0},
+ {LM3692X_BL_ADJ_THRESH, 0x0},
+ {LM3692X_BRT_LSB, 0x7},
+ {LM3692X_BRT_MSB, 0xff},
+ {LM3692X_FAULT_CTRL, 0x7},
+};
+
+static const struct regmap_config lm3692x_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LM3692X_FAULT_FLAGS,
+ .reg_defaults = lm3692x_reg_defs,
+ .num_reg_defaults = ARRAY_SIZE(lm3692x_reg_defs),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int lm3692x_fault_check(struct lm3692x_led *led)
+{
+ int ret;
+ unsigned int read_buf;
+
+ ret = regmap_read(led->regmap, LM3692X_FAULT_FLAGS, &read_buf);
+ if (ret)
+ return ret;
+
+ if (read_buf)
+ dev_err(&led->client->dev, "Detected a fault 0x%X\n", read_buf);
+
+ /* The first read may clear the fault. Check again to see if the fault
+ * still exits and return that value.
+ */
+ regmap_read(led->regmap, LM3692X_FAULT_FLAGS, &read_buf);
+ if (read_buf)
+ dev_err(&led->client->dev, "Second read of fault flags 0x%X\n",
+ read_buf);
+
+ return read_buf;
+}
+
+static int lm3692x_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brt_val)
+{
+ struct lm3692x_led *led =
+ container_of(led_cdev, struct lm3692x_led, led_dev);
+ int ret;
+ int led_brightness_lsb = (brt_val >> 5);
+
+ mutex_lock(&led->lock);
+
+ ret = lm3692x_fault_check(led);
+ if (ret) {
+ dev_err(&led->client->dev, "Cannot read/clear faults\n");
+ goto out;
+ }
+
+ ret = regmap_write(led->regmap, LM3692X_BRT_MSB, brt_val);
+ if (ret) {
+ dev_err(&led->client->dev, "Cannot write MSB\n");
+ goto out;
+ }
+
+ ret = regmap_write(led->regmap, LM3692X_BRT_LSB, led_brightness_lsb);
+ if (ret) {
+ dev_err(&led->client->dev, "Cannot write LSB\n");
+ goto out;
+ }
+out:
+ mutex_unlock(&led->lock);
+ return ret;
+}
+
+static int lm3692x_init(struct lm3692x_led *led)
+{
+ int ret;
+
+ if (led->regulator) {
+ ret = regulator_enable(led->regulator);
+ if (ret) {
+ dev_err(&led->client->dev,
+ "Failed to enable regulator\n");
+ return ret;
+ }
+ }
+
+ if (led->enable_gpio)
+ gpiod_direction_output(led->enable_gpio, 1);
+
+ ret = lm3692x_fault_check(led);
+ if (ret) {
+ dev_err(&led->client->dev, "Cannot read/clear faults\n");
+ goto out;
+ }
+
+ ret = regmap_write(led->regmap, LM3692X_BRT_CTRL, 0x00);
+ if (ret)
+ goto out;
+
+ /*
+ * For glitch free operation, the following data should
+ * only be written while device enable bit is 0
+ * per Section 7.5.14 of the data sheet
+ */
+ ret = regmap_write(led->regmap, LM3692X_PWM_CTRL,
+ LM3692X_PWM_FILTER_100 | LM3692X_PWM_SAMP_24MHZ);
+ if (ret)
+ goto out;
+
+ ret = regmap_write(led->regmap, LM3692X_BOOST_CTRL,
+ LM3692X_BRHT_MODE_RAMP_MULTI |
+ LM3692X_BL_ADJ_POL |
+ LM3692X_RAMP_RATE_250us);
+ if (ret)
+ goto out;
+
+ ret = regmap_write(led->regmap, LM3692X_AUTO_FREQ_HI, 0x00);
+ if (ret)
+ goto out;
+
+ ret = regmap_write(led->regmap, LM3692X_AUTO_FREQ_LO, 0x00);
+ if (ret)
+ goto out;
+
+ ret = regmap_write(led->regmap, LM3692X_BL_ADJ_THRESH, 0x00);
+ if (ret)
+ goto out;
+
+ ret = regmap_write(led->regmap, LM3692X_BRT_CTRL,
+ LM3692X_BL_ADJ_POL | LM3692X_PWM_HYSTER_4LSB);
+ if (ret)
+ goto out;
+
+ return ret;
+out:
+ dev_err(&led->client->dev, "Fail writing initialization values\n");
+
+ if (led->enable_gpio)
+ gpiod_direction_output(led->enable_gpio, 0);
+
+ if (led->regulator) {
+ ret = regulator_disable(led->regulator);
+ if (ret)
+ dev_err(&led->client->dev,
+ "Failed to disable regulator\n");
+ }
+
+ return ret;
+}
+
+static int lm3692x_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ int ret;
+ struct lm3692x_led *led;
+ struct device_node *np = client->dev.of_node;
+ struct device_node *child_node;
+ const char *name;
+
+ led = devm_kzalloc(&client->dev, sizeof(*led), GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ for_each_available_child_of_node(np, child_node) {
+ led->led_dev.default_trigger = of_get_property(child_node,
+ "linux,default-trigger",
+ NULL);
+
+ ret = of_property_read_string(child_node, "label", &name);
+ if (!ret)
+ snprintf(led->label, sizeof(led->label), "%s:%s",
+ np->name, name);
+ else
+ snprintf(led->label, sizeof(led->label),
+ "%s::backlight_cluster", id->name);
+ };
+
+ led->enable_gpio = devm_gpiod_get_optional(&client->dev,
+ "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(led->enable_gpio)) {
+ ret = PTR_ERR(led->enable_gpio);
+ dev_err(&client->dev, "Failed to get enable gpio: %d\n", ret);
+ return ret;
+ }
+
+ led->regulator = devm_regulator_get(&client->dev, "vled");
+ if (IS_ERR(led->regulator))
+ led->regulator = NULL;
+
+ led->client = client;
+ led->led_dev.name = led->label;
+ led->led_dev.brightness_set_blocking = lm3692x_brightness_set;
+
+ mutex_init(&led->lock);
+
+ i2c_set_clientdata(client, led);
+
+ led->regmap = devm_regmap_init_i2c(client, &lm3692x_regmap_config);
+ if (IS_ERR(led->regmap)) {
+ ret = PTR_ERR(led->regmap);
+ dev_err(&client->dev, "Failed to allocate register map: %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = lm3692x_init(led);
+ if (ret)
+ return ret;
+
+ ret = devm_led_classdev_register(&client->dev, &led->led_dev);
+ if (ret) {
+ dev_err(&client->dev, "led register err: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int lm3692x_remove(struct i2c_client *client)
+{
+ struct lm3692x_led *led = i2c_get_clientdata(client);
+ int ret;
+
+ if (led->enable_gpio)
+ gpiod_direction_output(led->enable_gpio, 0);
+
+ if (led->regulator) {
+ ret = regulator_disable(led->regulator);
+ if (ret)
+ dev_err(&led->client->dev,
+ "Failed to disable regulator\n");
+ }
+
+ mutex_destroy(&led->lock);
+
+ return 0;
+}
+
+static const struct i2c_device_id lm3692x_id[] = {
+ { "lm36922", 0 },
+ { "lm36923", 1 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, lm3692x_id);
+
+static const struct of_device_id of_lm3692x_leds_match[] = {
+ { .compatible = "ti,lm36922", },
+ { .compatible = "ti,lm36923", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_lm3692x_leds_match);
+
+static struct i2c_driver lm3692x_driver = {
+ .driver = {
+ .name = "lm3692x",
+ .of_match_table = of_lm3692x_leds_match,
+ },
+ .probe = lm3692x_probe,
+ .remove = lm3692x_remove,
+ .id_table = lm3692x_id,
+};
+module_i2c_driver(lm3692x_driver);
+
+MODULE_DESCRIPTION("Texas Instruments LM3692X LED driver");
+MODULE_AUTHOR("Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
--
2.15.0.124.g7668cbc60
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v9 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver
From: Dan Murphy @ 2017-12-11 18:26 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Dan Murphy
This adds the devicetree bindings for the LM3692x
I2C LED string driver.
Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
---
v9 - Moved 2 nodes to Optional Child and renamed node names to device type
https://patchwork.kernel.org/patch/10093757/
v8 - Added address-cells and size-cells as well as child node reg - https://patchwork.kernel.org/patch/10091259/
v7 - No changes - https://patchwork.kernel.org/patch/10087475/
v6 - No changes -https://patchwork.kernel.org/patch/10085567/
v5 - No Changes - https://patchwork.kernel.org/patch/10081071/
v4 - Fix example node, added trigger entry, removed ambiguous x for compatible and
added common.txt pointer for label - https://patchwork.kernel.org/patch/10060107
v3 - No changes
v2 - No changes - https://patchwork.kernel.org/patch/10056677/
.../devicetree/bindings/leds/leds-lm3692x.txt | 49 ++++++++++++++++++++++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3692x.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
new file mode 100644
index 000000000000..a93e19edfb42
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
@@ -0,0 +1,49 @@
+* Texas Instruments - LM3692x Highly Efficient White LED Driver
+
+The LM3692x is an ultra-compact, highly efficient,
+white-LED driver designed for LCD display backlighting.
+
+The main difference between the LM36922 and LM36923 is the number of
+LED strings it supports. The LM36922 supports two strings while the LM36923
+supports three strings.
+
+Required properties:
+ - compatible:
+ "ti,lm36922"
+ "ti,lm36923"
+ - reg : I2C slave address
+ - #address-cells : 1
+ - #size-cells : 0
+
+Optional properties:
+ - enable-gpios : gpio pin to enable/disable the device.
+ - vled-supply : LED supply
+
+Required child properties:
+ - reg : 0
+
+Optional child properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+ - linux,default-trigger :
+ see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+led-controller@36 {
+ compatible = "ti,lm3692x";
+ reg = <0x36>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ vled-supply = <&vbatt>;
+
+ led@0 {
+ reg = <0>;
+ label = "backlight_cluster";
+ linux,default-trigger = "backlight";
+ };
+}
+
+For more product information please see the link below:
+http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
--
2.15.0.124.g7668cbc60
--
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 v12 1/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation
From: Laurent Pinchart @ 2017-12-11 18:00 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Hans Verkuil, linux-media-u79uwXL29TY76Z2rM5mHXA, Sakari Ailus,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
tomoharu.fukawa.eb-zM6kxYcvzFBBDgjK7y7TUQ, Kieran Bingham,
Geert Uytterhoeven, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171129193235.25423-2-niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
Hi Niklas,
Thank you for the patch.
On Wednesday, 29 November 2017 21:32:34 EET Niklas Söderlund wrote:
> Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> are located between the video sources (CSI-2 transmitters) and the video
> grabbers (VIN) on Gen3 of Renesas R-Car SoC.
>
> Each CSI-2 device is connected to more then one VIN device which
s/then/than/
> simultaneously can receive video from the same CSI-2 device. Each VIN
> device can also be connected to more then one CSI-2 device. The routing
s/then/than/
> of which link are used are controlled by the VIN devices. There are only
s/link are/links are/ or s/link are/link is/
s/are controlled/is controlled/
> a few possible routes which are set by hardware limitations, which are
> different for each SoC in the Gen3 family.
>
> To work with the limitations of routing possibilities it is necessary
> for the DT bindings to describe which VIN device is connected to which
> CSI-2 device. This is why port 1 needs to to assign reg numbers for each
> VIN device that be connected to it. To setup and to know which links are
s/that be/that is/
> valid for each SoC is the responsibility of the VIN driver since the
> register to configure it belongs to the VIN hardware.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> .../bindings/media/renesas,rcar-csi2.txt | 105 ++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 106 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt new file
> mode 100644
> index 0000000000000000..688afd83bf66f8cf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> @@ -0,0 +1,105 @@
> +Renesas R-Car MIPI CSI-2
> +------------------------
> +
> +The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
rcar-csi2 is the name of the driver, I would call it the "R-Car CSI-2 receiver
device" (or s/device/IP core/).
> +family of devices. It is to be used in conjunction with the R-Car VIN
> module,
The IP core itself doesn't have to be used with the VIN, but in R-Car SoCs it
is, so I would phrase it as "It is used ...".
> +which provides the video capture capabilities.
> +
> +Mandatory properties
> +--------------------
> + - compatible: Must be one or more of the following
> + - "renesas,r8a7795-csi2" for the R8A7795 device.
> + - "renesas,r8a7796-csi2" for the R8A7796 device.
> +
> + - reg: the register base and size for the device registers
> + - interrupts: the interrupt for the device
> + - clocks: Reference to the parent clock
Either capitalize the first word after the colon or don't, but please don't
mix them :-)
> +
> +The device node shall contain two 'port' child nodes according to the
> +bindings defined in Documentation/devicetree/bindings/media/
> +video-interfaces.txt. Port 0 shall connect the node that is the video
> +source for to the CSI-2.
Or simply "Port 0 shall connect to the CSI-2 source." ?
> Port 1 shall connect all the R-Car VIN
> +modules, which can make use of the CSI-2 module.
And to be a bit more explicit, how about "Port 1 shall connect to all the R-
Car VIN modules that have a hardware connection to the CSI-2 receiver." ?
> +
> +- Port 0 - Video source (Mandatory)
Nitpicking, I don't think you need to capitalize Mandatory.
> + - Endpoint 0 - sub-node describing the endpoint that is the video source
> +
> +- Port 1 - VIN instances (Mandatory for all VIN present in the SoC)
> + - Endpoint 0 - sub-node describing the endpoint that is VIN0
> + - Endpoint 1 - sub-node describing the endpoint that is VIN1
> + - Endpoint 2 - sub-node describing the endpoint that is VIN2
> + - Endpoint 3 - sub-node describing the endpoint that is VIN3
> + - Endpoint 4 - sub-node describing the endpoint that is VIN4
> + - Endpoint 5 - sub-node describing the endpoint that is VIN5
> + - Endpoint 6 - sub-node describing the endpoint that is VIN6
> + - Endpoint 7 - sub-node describing the endpoint that is VIN7
Should we clarify that only a subset of those endpoints shall be present when
the CSI-2 receiver isn't connected to all VIN instances ?
Furthermore, as explained in a comment I made when reviewing the VIN patch
series, I wonder whether we shouldn't identify the CSI-2 receiver instances by
ID the same way we do with the VIN instances (using the renesas,id property).
In that case I think the endpoint numbering won't matter.
> +Example:
> +
> + csi20: csi2@fea80000 {
> + compatible = "renesas,r8a7796-csi2";
> + reg = <0 0xfea80000 0 0x10000>;
> + interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 714>;
> + power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
> + resets = <&cpg 714>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <0>;
> +
> + csi20_in: endpoint@0 {
> + reg = <0>;
> + clock-lanes = <0>;
> + data-lanes = <1>;
> + remote-endpoint = <&adv7482_txb>;
> + };
> + };
> +
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <1>;
> +
> + csi20vin0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&vin0csi20>;
> + };
> + csi20vin1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&vin1csi20>;
> + };
> + csi20vin2: endpoint@2 {
> + reg = <2>;
> + remote-endpoint = <&vin2csi20>;
> + };
> + csi20vin3: endpoint@3 {
> + reg = <3>;
> + remote-endpoint = <&vin3csi20>;
> + };
> + csi20vin4: endpoint@4 {
> + reg = <4>;
> + remote-endpoint = <&vin4csi20>;
> + };
> + csi20vin5: endpoint@5 {
> + reg = <5>;
> + remote-endpoint = <&vin5csi20>;
> + };
> + csi20vin6: endpoint@6 {
> + reg = <6>;
> + remote-endpoint = <&vin6csi20>;
> + };
> + csi20vin7: endpoint@7 {
> + reg = <7>;
> + remote-endpoint = <&vin7csi20>;
> + };
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index aa71ab52fd76d160..4737de9f41bff570 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8652,6 +8652,7 @@ L: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> L: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> T: git git://linuxtv.org/media_tree.git
> S: Supported
> +F: Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> F: Documentation/devicetree/bindings/media/rcar_vin.txt
> F: drivers/media/platform/rcar-vin/
--
Regards,
Laurent Pinchart
--
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 V3 0/2] Tegra PCIe end point config space map code refactoring
From: Bjorn Helgaas @ 2017-12-11 17:54 UTC (permalink / raw)
To: Thierry Reding
Cc: Bjorn Helgaas, Vidya Sagar, treding, linux-tegra, linux-pci,
kthota, mmaddireddy, robh+dt, devicetree, Lorenzo Pieralisi
In-Reply-To: <20171211105431.GI10671@ulmo>
[+cc Lorenzo]
On Mon, Dec 11, 2017 at 11:54:31AM +0100, Thierry Reding wrote:
> On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote:
> > PCIe host controller in Tegra SoCs has 1GB of aperture available
> > for mapping end points config space, IO and BARs. In that, currently
> > 256MB is being reserved for mapping end points configuration space
> > which leaves less memory space available for mapping end points BARs
> > on some of the platforms.
> > This patch series attempts to map only 4K space from 1GB aperture to
> > access end points configuration space.
> >
> > Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> > to use for BAR mapping) physical space as well as kernel virtual mapping space,
> > it saves only kernel virtual address space in T30, T124, T132 and T210.
> >
> > NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> > merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> > For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> > DT modifications
> >
> > Testing Done on T124, T210 & T186:
> > Enumeration and basic functionality of immediate devices
> > Enumeration of devices behind a PCIe switch
> > Complete 4K configuration space access
> >
> > Vidya Sagar (2):
> > PCI: tegra: refactor config space mapping code
> > ARM64: tegra: limit PCIe config space mapping to 4K for T186
> >
> > arch/arm64/boot/dts/nvidia/tegra186.dtsi | 8 +-
> > drivers/pci/host/pci-tegra.c | 125 ++++++++++---------------------
> > 2 files changed, 44 insertions(+), 89 deletions(-)
>
> Hi Bjorn,
>
> there's a bunch of PCI related patches for Tegra floating around on the
> lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> tree after they've been reviewed and send you a pull request later on
> (say around v4.15-rc6). That would allow me to get things cooking in
> linux-next for a bit and get broader testing in addition to the
> flexibility to patch things up if they break.
Lorenzo will be merging the Tegra stuff, so this is more a question
for him.
Just to clarify, I think your questions is about putting those patches
in
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
If you put them there they will show up in linux-next, and then when
Lorenzo merges them, you'll have to coordinate so they don't get
merged into linux-next twice (once via the usual PCI tree route and
again via the Tegra tree).
If you wait until after they've been reviewed to put them into the
Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
would merge them at about that same point.
This cycle isn't going to be ideal timing with all the holidays
coming up. I know I'm going to be traveling and on vacation quite a
bit in the rc5, 6, 7 timeframe.
Bjorn
^ permalink raw reply
* Re: [alsa-devel] [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver
From: Vinod Koul @ 2017-12-11 17:48 UTC (permalink / raw)
To: Mark Brown
Cc: Katsuhiro Suzuki, devicetree, alsa-devel, Masami Hiramatsu,
Yamada, Masahiro/山田 真弘, linux-kernel,
Jassi Brar, Rob Herring, linux-arm-kernel
In-Reply-To: <20171211151629.GD9854@sirena.org.uk>
On Mon, Dec 11, 2017 at 03:16:29PM +0000, Mark Brown wrote:
> On Mon, Dec 11, 2017 at 06:21:58PM +0900, Katsuhiro Suzuki wrote:
>
> > But I can't find how to use/map this DAI in machine driver or Device-Tree or
> > something. I think that it's same as PCM DAI, am I correct?
>
> Yes, that probably makes sense from a binding point of view.
>
> > I read compress-offload.rst, but I can't find how do I test it. It seems aplay
> > of
> > alsa-util doesn't know compress audio formats. Should I use PulseAudio or
> > Android HAL to test compress audio APIs?
>
> IIRC tinyalsa has a compressed API test application - Vinod?
I guess it was sheer luck that i saw this :) email in CC reads
vinod.koul@linaro.org! I don't work for Linaro, not yet :D
And to the answer the question, Yes we have compressed API test application
in tinycompress which is located at git.alsa-project.org:tinycompress.git
We have both compressed audio playback as well as record test app, cplay and
crecord.
HTH
--
~Vinod
^ permalink raw reply
* [PATCH v10 1/4] dt-bindings: media: Document Synopsys DesignWare HDMI RX
From: Jose Abreu @ 2017-12-11 17:41 UTC (permalink / raw)
To: linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Jose Abreu, Joao Pinto, Rob Herring, Mark Rutland,
Mauro Carvalho Chehab, Hans Verkuil, Sylwester Nawrocki,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1513013948.git.joabreu-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Document the bindings for the Synopsys DesignWare HDMI RX.
Signed-off-by: Jose Abreu <joabreu-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> (v8)
Cc: Joao Pinto <jpinto-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Mauro Carvalho Chehab <mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
Cc: Sylwester Nawrocki <snawrocki-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
Changes from v7:
- Remove SoC specific bindings (Rob)
Changes from v6:
- Document which properties are required/optional (Sylwester)
- Drop compatible string for SoC (Sylwester)
- Reword edid-phandle property (Sylwester)
- Typo fixes (Sylwester)
Changes from v4:
- Use "cfg" instead of "cfg-clk" (Rob)
- Change node names (Rob)
Changes from v3:
- Document the new DT bindings suggested by Sylwester
Changes from v2:
- Document edid-phandle property
---
.../devicetree/bindings/media/snps,dw-hdmi-rx.txt | 58 ++++++++++++++++++++++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
new file mode 100644
index 0000000..1dc09c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
@@ -0,0 +1,58 @@
+Synopsys DesignWare HDMI RX Decoder
+===================================
+
+This document defines device tree properties for the Synopsys DesignWare HDMI
+RX Decoder (DWC HDMI RX).
+
+The properties bellow belong to the Synopsys DesignWare HDMI RX Decoder node.
+
+Required properties:
+
+- compatible: Shall be "snps,dw-hdmi-rx".
+- reg: Memory mapped base address and length of the DWC HDMI RX registers.
+- interrupts: Reference to the DWC HDMI RX interrupt and the HDMI 5V sense
+interrupt.
+- clocks: Reference to the config clock.
+- clock-names: Shall be "cfg".
+- #address-cells: Shall be 1.
+- #size-cells: Shall be 0.
+
+Optional properties:
+
+- edid-phandle: Reference to the EDID handler block; if this property is not
+specified it is assumed that EDID is handled by device described by parent
+node of the HDMI RX node. You should not specify this property if your HDMI RX
+controller does not have CEC.
+
+You also have to create a subnode for the PHY device. PHY node properties are
+as follows.
+
+Required properties:
+
+- compatible: Shall be "snps,dw-hdmi-phy-e405".
+- reg: Shall be the JTAG address of the PHY.
+- clocks: Reference to the config clock.
+- clock-names: Shall be "cfg".
+
+Example:
+
+hdmi_rx: hdmi-rx@0 {
+ compatible = "snps,dw-hdmi-rx";
+ reg = <0x0 0x10000>;
+ interrupts = <1 2>;
+ edid-phandle = <&dw_hdmi_edid>;
+
+ clocks = <&dw_hdmi_refclk>;
+ clock-names = "cfg";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-phy@fc {
+ compatible = "snps,dw-hdmi-phy-e405";
+ reg = <0xfc>;
+
+ clocks = <&dw_hdmi_refclk>;
+ clock-names = "cfg";
+ };
+};
--
1.9.1
--
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 02/12] mtd: nand: add reworked Marvell NAND controller driver
From: Boris Brezillon @ 2017-12-11 17:05 UTC (permalink / raw)
To: Miquel RAYNAL
Cc: Ezequiel Garcia, David Woodhouse, Brian Norris, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Russell King, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Eric Miao, Catalin Marinas, Will Deacon <will.>
In-Reply-To: <20171211175506.0b8ea4d1@xps13>
On Mon, 11 Dec 2017 17:55:06 +0100
Miquel RAYNAL <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Mon, 11 Dec 2017 13:27:30 -0300
> Ezequiel Garcia <ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ@public.gmane.org> wrote:
>
> > On 7 December 2017 at 17:18, Miquel Raynal
> > <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > > Add marvell_nand driver which aims at replacing the existing
> > > pxa3xx_nand driver.
> > >
> > > The new driver intends to be easier to understand and follows the
> > > brand new NAND framework rules by implementing hooks for every
> > > pattern the controller might support and referencing them inside a
> > > parser object that will be given to the core at each ->exec_op()
> > > call.
> > >
> > > Raw accessors are implemented, useful to test/debug
> > > memory/filesystem corruptions. Userspace binaries contained in the
> > > mtd-utils package may now be used and their output trusted.
> > >
> > > Timings may not be kept from the bootloader anymore, the timings
> > > used for instance in U-Boot were not optimal and it supposed to
> > > have NAND support (and initialized) in the bootloader.
> > >
> > > Thanks to the improved timings, implementation of ONFI mode 5
> > > support (with EDO managed by adding a delay on data sampling),
> > > merging the commands together and optimizing writes in the command
> > > registers, the new driver may achieve faster throughputs in both
> > > directions. Measurements show an improvement of about +23% read
> > > throughput and +24% write throughput. These measurements have been
> > > done with an Armada-385-DB-AP (4kiB NAND pages forced in 4-bit
> > > strength BCH ECC correction) using the userspace tool 'flash_speed'
> > > from the MTD test suite.
> > >
> > > Besides these important topics, the new driver addresses several
> > > unsolved known issues in the old driver which:
> > > - did not work with ECC soft neither with ECC none ;
> > > - relied on naked read/write (which is unchanged) while the NFCv1
> > > embedded in the pxa3xx platforms do not implement it, so several
> > > NAND commands did not actually ever work without any notice (like
> > > reading the ONFI PARAM_PAGE or SET/GET_FEATURES) ;
> > > - wrote the OOB data correctly, but was not able to read it
> > > correctly past the first OOB data chunk ;
> > > - did not displayed ECC bytes ;
> > > - used device tree bindings that did not allow more than one NAND
> > > chip, and did not allow to choose the correct chip select if not
> > > incrementing from 0. Plus, the Ready/Busy line used had to be 0.
> > >
> > > Old device tree bindings are still supported but deprecated. A more
> > > hierarchical view has to be used to keep the controller and the NAND
> > > chip structures clearly separated both inside the device tree and
> > > also in the driver code.
> > >
> >
> > So, is this driver fully compatible with the current pxa3xx-nand
> > driver?
>
> It should be!
>
> >
> > Have you tested with U-Boot's driver (based on the pxa3xx-nand)?
> >
> > I recally some subtle issues with the fact that U-Boot and Linux had
> > to agree about the BBT format.
>
> I kept the pxa3xx_nand driver BBT format.
>
> This is something I mistakenly omitted from the commit message:
>
> There are 5 supported layouts in the driver (the same as withing the
> pxa3xx_nand driver):
> 1/ Page: 512B, strength 1b/512B (hamming)
> 2/ Page: 2kiB, strength 4b/2kiB (hamming)
> 3/ page: 2kiB, strength 16b/2kiB (BCH)
> 4/ page: 4kiB, strength 16b/2kiB (BCH)
> 5/ page: 4kiB, strength 32b/2kiB (BCH)
Are you sure of #5? I thought the engine was only capable of modifying
the ECC block size, not the strength. If this is the case, then mode #5
is actually 16b/1024kiB.
>
> Layout 2 has been tested with CM_X300 compulab module (PXA SoC) with
> and without DMA.
> Layout 4 has been tested with an Armada 385 db, an Armada 7040 DB and
> an Armada 8040 DB.
> Layout 5 has been tested with an Armada 398 db.
>
> Layout 1 has been tested with the Armada 385 db with some hacks.
> Layout 3 has been tested with the Armada 385 db with some other hacks,
> that is why I am concerned about the other thread on the MTD mailing
> list "wait timeout when scanning for BB" where a 2kiB page with
> 16b/2048B strength is in use.
>
> Regards,
> Miquèl
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] thermal: armada: add support for CP110
From: Gregory CLEMENT @ 2017-12-11 17:02 UTC (permalink / raw)
To: Baruch Siach, Ezequiel Garcia
Cc: Miquel RAYNAL, Zhang Rui, Eduardo Valentin, devicetree,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Russell King,
linux-pm, linux-arm-kernel
In-Reply-To: <20171211152731.glkkes5errcxmsvz@sapphire.tkos.co.il>
Hi Baruch,
On lun., déc. 11 2017, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miquel,
>
> On Mon, Dec 11, 2017 at 04:09:32PM +0100, Miquel RAYNAL wrote:
>> On Sun, 3 Dec 2017 13:11:23 +0200
>> Baruch Siach <baruch@tkos.co.il> wrote:
>>
>> > The CP110 component is integrated in the Armada 8k and 7k lines of
>> > processors.
>> >
>> > This patch also adds an option of offset to the MSB of the control
>> > register. The existing DT binding for Armada 38x refers to a single
>> > 32 bit control register. It turns out that this is actually only the
>> > MSB of the control area. Changing the binding to fix that would break
>> > existing DT files, so the Armada 38x binding is left as is.
>> >
>> > The new CP110 binding increases the size of the control area to 64
>> > bits, thus moving the MSB to offset 4.
>> >
>> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>> > ---
>> > v2: No change
>> > ---
>> > drivers/thermal/armada_thermal.c | 24 ++++++++++++++++++++++--
>> > 1 file changed, 22 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/thermal/armada_thermal.c
>> > b/drivers/thermal/armada_thermal.c index 0eb82097571f..59b75f63945d
>> > 100644 --- a/drivers/thermal/armada_thermal.c
>> > +++ b/drivers/thermal/armada_thermal.c
>> > @@ -73,6 +73,7 @@ struct armada_thermal_data {
>> > unsigned int temp_shift;
>> > unsigned int temp_mask;
>> > unsigned int is_valid_shift;
>> > + unsigned int control_msb_offset;
>> > };
>> >
>> > static void armadaxp_init_sensor(struct platform_device *pdev,
>> > @@ -142,12 +143,14 @@ static void armada375_init_sensor(struct
>> > platform_device *pdev, static void armada380_init_sensor(struct
>> > platform_device *pdev, struct armada_thermal_priv *priv)
>> > {
>> > - unsigned long reg = readl_relaxed(priv->control);
>> > + void __iomem *control_msb =
>> > + priv->control + priv->data->control_msb_offset;
>> > + unsigned long reg = readl_relaxed(control_msb);
>> >
>> > /* Reset hardware once */
>> > if (!(reg & A380_HW_RESET)) {
>> > reg |= A380_HW_RESET;
>> > - writel(reg, priv->control);
>> > + writel(reg, control_msb);
>> > mdelay(10);
>> > }
>> > }
>> > @@ -266,6 +269,19 @@ static const struct armada_thermal_data
>> > armada_ap806_data = { .signed_sample = true,
>> > };
>> >
>> > +static const struct armada_thermal_data armada_cp110_data = {
>> > + .is_valid = armada_is_valid,
>> > + .init_sensor = armada380_init_sensor,
>>
>> I see the initialization for CP110 thermal IP is close to
>> Armada-380's, but, as you point it in the commit log it is still
>> different.
>>
>> I don't know what is the best way to handle this but until now each
>> new compatible had his own ->init_sensor function, shouldn't we do
>> the same here as changes are requested? This would naturally avoid the
>> situation with Armada-380 bindings.
>
> I'm not sure I understand your suggestion.
>
> There is no difference between the CP110 and the Armada 38x, as far as I can
> see. The only quirk is that the existing Armada 38x DT binding is wrong I that
> the 'reg' property references the control MSB, while leaving the LSB
> out. We
Well I would not say it was wrong but more incomplete :)
> can't change the Armada 38x binding without breaking existing DTs. The
> 'control_msb_offset' field that this patch adds allows correct binding for
> CP110, while keeping compatibility with the existing Armada 38x
> binding.
I am not against adding a new compatible string for CP110 but ot be
honest the new binding for CP110 does not bring anything as you don't
use at all the LSB register.
Actually, if on Armada 375 we initially mapped the LSB register it was
to support an very early release of the SoC (stepping Z) and only for
resetting its value. So I guess you started to write the AP860 part
based on the Armada 375 and then found that we could map a more complete
range of the registers.
>
> How would a separate init_sensor routine improve things?
So yes please do it, thanks to this you won't have to add the
control_msb_offset member and can use a clean function. Moreover if in
the future we see some usefulness for this LSB register then we could use
the new compatible for the Armada 38x.
Thanks,
Gregory
>
> baruch
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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 1/2] dt-bindings: Add binding for Sitronix ST7735R display panels
From: Noralf Trønnes @ 2017-12-11 16:59 UTC (permalink / raw)
To: David Lechner, dri-devel, devicetree
Cc: Mark Rutland, limor, linux-kernel, Rob Herring
In-Reply-To: <1512943833-31352-2-git-send-email-david@lechnology.com>
Den 10.12.2017 23.10, skrev David Lechner:
> This adds a new device tree binding for Sitronix ST7735R display panels,
> such as the Adafruit 1.8" TFT.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>
> v2: changes:
> * None, but...
>
> I'm wondering about my choice of compatible here. I chose the name
> "sitronix,st7735r-jd-t18003-t01" to mean a Sitronix ST7735R controller
> connected to a JD-T18003-T01 LCD screen.
>
> What I am actually using, though, is an Adafruit 1.8" TFT breakout [1]. It
> has some additional electronics which just pass through signals to the
> controller. The bare display is also available from Adafruit [2].
>
> Limor brought up an interesting point in an off-list discussion. The
> same controller can be wired to the same LCD in different ways. This is
> evident in the fbftf drivers in staging. There is an "adafruit18" and an
> "adafruit18_green" in fbftf_devices.c where apparently, two otherwise
> identical displays were wired slightly differently at the factory so that
> on one, the on-board GRAM word 0 does not correspond to pixel 0,0 on the
> LCD. It requires a special offset to the GRAM starting address in order to
> have the image displayed correctly.
>
> Additionally, fbtft supports a SainSmart 1.8" TFT [3] that uses the same
> controller, but it appears that these have different gamma curves (perhaps
> they use different LCDs?). The available pins are exactly the same as the
> Adafruit display though.
>
> As I am writing this, I am looking at the JD-1800 datasheet [4] again for
> the Adafruit display and I see that in addition to specifying the size of
> the display it says "IC: ST7735B". So, I am starting to think that "jianda,
> jd-t18003-t01" would be a better compatible string since it tells you
> everything you need to know about this display. Just using the controller
> name by itself ("sitronix,st7735r") is not enough because it does not tell
> you things like the number of pixels or the physical size of the LCD.
>
> What I am not sure about, though, is how to represent the Adafruit display
> that requires the offset in the device tree. Would it be a different
> compatible string or should we add an extra property to indicate this
> quirk?
>
> On a related note, I recently submitted device tree bindings for a similar
> SPI display breakout board [5][6]. After more digging though, I found a
> datasheet for that display [7], so I'm thinking a compatible string of
> "vot,v220hf01a-t" would be better by the same reasoning above.
>
> And, I know this is getting long, but one more thing...
>
> There was a binding acked recently for the LCD on a D-Link DIR-685 Wireless
> N Storage Router [8]. This uses the compound compatible string of "dlink,
> dir-685-panel", "ilitek,ili9322". If we want to try to keep things
> consistent, perhaps I should be adopting this pattern as well? And perhaps
> it would be better to use the better known vendor name instead of the
> obscure vendors from the datasheets that I have found? For example,
> "adafruit,618" "sitronix,st7735r" instead of "jianda,jd-t18003-t01"?
I vote for this:
"jianda,jd-t18003-t01"
The display controller is part of the panel so you can't have this
panel with another controller. If the Adafruit #358 panel with
breakout board did something that made it incompatible with a bare
jianda panel, then it would make sense to call it "adafruit,something".
I don't know the full story about the green tab version of the display
with the offset problem, but it's a long time ago and I don't think
it's worth it to support it. It would require a custom dirtyfb callback.
There's also a black tab version of this Adafruit display with the
colors reversed BGR/RGB, but that also is some time back now.
I guess they all had different panels with their own names which would
result in different compatible strings. This means that the end user
would have to know excatly which version of the Adafruit display they're
using to know which compatible string to use. If the SPI MISO signal
had been routed out from the panel, it would have been possible to make
a driver just with a "adafruit,tft18" comaptible and let the driver ask
the controller which version it is. Assuming that info is available in
the controller. Not all panel vendors bother to do that.
The "mi,mi0283qt" panel for instance is used on the Adafruit PiTFT 28
and the Watterott rpi-display, making it possible to use the same
compatible for both displays and also for anyone buying that panel from
some other source.
One last thing, if the panel is made specifically for Adafruit and not
available from any other source, then it makes sense to call it
something "adafruit".
Noralf.
> [1]: https://www.adafruit.com/product/358
> [2]: https://www.adafruit.com/product/618
> [3]: https://www.sainsmart.com/products/1-8-tft-spi-lcd-screen-with-microsd-socket
> [4]: http://www.adafruit.com/datasheets/JD-T1800.pdf
> [5]: https://patchwork.freedesktop.org/patch/187038/
> [6]: https://patchwork.freedesktop.org/patch/189233/
> [7]: http://www.hotmcu.com/22-176x220-tft-lcd-with-spi-interface-p-316.html
> [8]: https://patchwork.freedesktop.org/patch/191462/
>
> .../bindings/display/sitronix,st7735r.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sitronix,st7735r.txt
>
> diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.txt b/Documentation/devicetree/bindings/display/sitronix,st7735r.txt
> new file mode 100644
> index 0000000..bbb8ba6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.txt
> @@ -0,0 +1,35 @@
> +Sitronix ST7735R display panels
> +
> +This binding is for display panels using a Sitronix ST7735R controller in SPI
> +mode.
> +
> +Required properties:
> +- compatible: "sitronix,st7735r-jd-t18003-t01"
> +- dc-gpios: Display data/command selection (D/CX)
> +- reset-gpios: Reset signal (RSTX)
> +
> +The node for this driver must be a child node of a SPI controller, hence
> +all mandatory properties described in ../spi/spi-bus.txt must be specified.
> +
> +Optional properties:
> +- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> +
> + backlight: backlight {
> + compatible = "gpio-backlight";
> + gpios = <&gpio 44 GPIO_ACTIVE_HIGH>;
> + }
> +
> + ...
> +
> + display@0{
> + compatible = "sitronix,st7735r-jd-t18003-t01";
> + reg = <0>;
> + spi-max-frequency = <32000000>;
> + dc-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
> + rotation = <270>;
> + backlight = &backlight;
> + };
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 20/20] ARM: dts: imx6qdl-hummingboard2: rename regulators to match schematic
From: Russell King @ 2017-12-11 16:59 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Make the regulators match the schematic - name the regulators after
one of their schematic supply names, and arrange them into their
heirarchy.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi | 4 +-
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 86 ++++++++++++++---------
2 files changed, 56 insertions(+), 34 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi
index 1aa97817e751..f400405381a7 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi
@@ -64,8 +64,8 @@
&usdhc3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usdhc3>;
- vmmc-supply = <®_3p3v>;
- vqmmc-supply = <®_3p3v>;
+ vmmc-supply = <&v_3v2>;
+ vqmmc-supply = <&v_3v2>;
bus-width = <8>;
non-removable;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 1089f693ebde..117c4daf31e9 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -52,20 +52,29 @@
linux,rc-map-name = "rc-rc6-mce";
};
- reg_3p3v: regulator-3p3v {
+ v_3v2: regulator-v-3v2 {
compatible = "regulator-fixed";
- regulator-name = "VCC_3V2";
- regulator-min-microvolt = <3300000>;
+ regulator-always-on;
regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "v_3v2";
+ };
+
+ v_5v0: regulator-v-5v0 {
+ compatible = "regulator-fixed";
regulator-always-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "v_5v0";
};
- reg_1p8v: regulator-1p8v {
+ vcc_1p8: regulator-vcc-1p8 {
compatible = "regulator-fixed";
- regulator-name = "VCC_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
regulator-always-on;
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "vcc_1p8";
+ vin-supply = <&v_3v2>;
};
v_sd: regulator-v-sd {
@@ -78,53 +87,62 @@
regulator-min-microvolt = <3300000>;
regulator-name = "v_sd";
startup-delay-us = <1000>;
+ vin-supply = <&v_3v2>;
};
- reg_usbh2_vbus: regulator-usb-h1-vbus {
+ v_usb1: regulator-v-usb1 {
compatible = "regulator-fixed";
enable-active-high;
- gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_hummingboard2_usbh1_vbus>;
- regulator-name = "V_USB2";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
+ pinctrl-0 = <&pinctrl_hummingboard2_usbotg_vbus>;
regulator-always-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "v_usb1";
+ vin-supply = <&v_5v0>;
};
- reg_usbotg_vbus: regulator-usb-otg-vbus {
+ v_usb2: regulator-v-usb2 {
+ /* USB hub port 1 */
compatible = "regulator-fixed";
enable-active-high;
- gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_hummingboard2_usbotg_vbus>;
- regulator-name = "V_USB1";
- regulator-min-microvolt = <5000000>;
+ pinctrl-0 = <&pinctrl_hummingboard2_usbh1_vbus>;
+ regulator-always-on;
regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "v_usb2";
+ vin-supply = <&v_5v0>;
};
- reg_usbh3_vbus: regulator-usb-h2-vbus {
+ v_usb3: regulator-v-usb3 {
+ /* USB hub port 3 */
compatible = "regulator-fixed";
enable-active-high;
- enable-gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
+ gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usbh2_vbus>;
- regulator-name = "V_USB3";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
regulator-always-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "v_usb3";
+ vin-supply = <&v_5v0>;
};
- reg_usbh4_vbus: regulator-usb-h3-vbus {
+ v_usb4: regulator-v-usb4 {
+ /* USB hub port 4 */
compatible = "regulator-fixed";
enable-active-high;
- enable-gpio = <&gpio7 10 GPIO_ACTIVE_HIGH>;
+ gpio = <&gpio7 10 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usbh3_vbus>;
- regulator-name = "V_USB4";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
regulator-always-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "v_usb4";
+ vin-supply = <&v_5v0>;
};
sound-sgtl5000 {
@@ -176,9 +194,9 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_sgtl5000>;
reg = <0x0a>;
- VDDA-supply = <®_3p3v>;
- VDDIO-supply = <®_3p3v>;
- VDDD-supply = <®_1p8v>;
+ VDDA-supply = <&v_3v2>;
+ VDDD-supply = <&vcc_1p8>;
+ VDDIO-supply = <&v_3v2>;
};
};
@@ -488,7 +506,7 @@
disable-over-current;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usbotg_id>;
- vbus-supply = <®_usbotg_vbus>;
+ vbus-supply = <&v_usb1>;
status = "okay";
};
@@ -516,3 +534,7 @@
pinctrl-0 = <&pinctrl_hummingboard2_uart3>;
status = "okay";
};
+
+&vcc_3v3 {
+ vin-supply = <&v_3v2>;
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 19/20] ARM: dts: imx6qdl-hummingboard2: add v1.5 som with eMMC
From: Russell King @ 2017-12-11 16:58 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Add support for the v1.5 SOM with TI Wi-Fi and eMMC. As the pinmux
settings are different for the microsom, we need to use a separate
board-level dts for this as there is no support for overlays.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 2 +
.../boot/dts/imx6dl-hummingboard2-emmc-som-v15.dts | 55 +++++++++++++++++++
.../boot/dts/imx6q-hummingboard2-emmc-som-v15.dts | 63 ++++++++++++++++++++++
3 files changed, 120 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-hummingboard2-emmc-som-v15.dts
create mode 100644 arch/arm/boot/dts/imx6q-hummingboard2-emmc-som-v15.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b72799b464b5..458e2c886c0e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -389,6 +389,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-hummingboard-emmc-som-v15.dtb \
imx6dl-hummingboard-som-v15.dtb \
imx6dl-hummingboard2.dtb \
+ imx6dl-hummingboard2-emmc-som-v15.dtb \
imx6dl-hummingboard2-som-v15.dtb \
imx6dl-icore.dtb \
imx6dl-icore-rqs.dtb \
@@ -450,6 +451,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-hummingboard-emmc-som-v15.dtb \
imx6q-hummingboard-som-v15.dtb \
imx6q-hummingboard2.dtb \
+ imx6q-hummingboard2-emmc-som-v15.dtb \
imx6q-hummingboard2-som-v15.dtb \
imx6q-icore.dtb \
imx6q-icore-ofcap10.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-hummingboard2-emmc-som-v15.dts b/arch/arm/boot/dts/imx6dl-hummingboard2-emmc-som-v15.dts
new file mode 100644
index 000000000000..80313c13bcdb
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-hummingboard2-emmc-som-v15.dts
@@ -0,0 +1,55 @@
+/*
+ * Device Tree file for SolidRun HummingBoard2
+ * Copyright (C) 2015 Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
+ * Based on work by Russell King
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-sr-som.dtsi"
+#include "imx6qdl-sr-som-emmc.dtsi"
+#include "imx6qdl-sr-som-ti.dtsi"
+#include "imx6qdl-hummingboard2.dtsi"
+
+/ {
+ model = "SolidRun HummingBoard2 Solo/DualLite (1.5som+emmc)";
+ compatible = "solidrun,hummingboard2/dl", "fsl,imx6dl";
+};
diff --git a/arch/arm/boot/dts/imx6q-hummingboard2-emmc-som-v15.dts b/arch/arm/boot/dts/imx6q-hummingboard2-emmc-som-v15.dts
new file mode 100644
index 000000000000..1998ebfa0fe0
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-hummingboard2-emmc-som-v15.dts
@@ -0,0 +1,63 @@
+/*
+ * Device Tree file for SolidRun HummingBoard2
+ * Copyright (C) 2015 Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
+ * Based on work by Russell King
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-sr-som.dtsi"
+#include "imx6qdl-sr-som-emmc.dtsi"
+#include "imx6qdl-sr-som-ti.dtsi"
+#include "imx6qdl-hummingboard2.dtsi"
+
+/ {
+ model = "SolidRun HummingBoard2 Dual/Quad (1.5som+emmc)";
+ compatible = "solidrun,hummingboard2/q", "fsl,imx6q";
+};
+
+&sata {
+ status = "okay";
+ fsl,transmit-level-mV = <1104>;
+ fsl,transmit-boost-mdB = <0>;
+ fsl,transmit-atten-16ths = <9>;
+ fsl,no-spread-spectrum;
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 18/20] ARM: dts: imx6qdl-hummingboard2: add v1.5 som without eMMC
From: Russell King @ 2017-12-11 16:58 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Add support for the v1.5 SOM with TI Wi-Fi but without eMMC. As the
pinmux settings are different for the microsom, we need to use a
separate board-level dts for this as there is no support for overlays.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-hummingboard2-som-v15.dts | 54 +++++++++++++++++++
arch/arm/boot/dts/imx6q-hummingboard2-som-v15.dts | 62 ++++++++++++++++++++++
3 files changed, 118 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-hummingboard2-som-v15.dts
create mode 100644 arch/arm/boot/dts/imx6q-hummingboard2-som-v15.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a757e2dd60c4..b72799b464b5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -389,6 +389,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-hummingboard-emmc-som-v15.dtb \
imx6dl-hummingboard-som-v15.dtb \
imx6dl-hummingboard2.dtb \
+ imx6dl-hummingboard2-som-v15.dtb \
imx6dl-icore.dtb \
imx6dl-icore-rqs.dtb \
imx6dl-nit6xlite.dtb \
@@ -449,6 +450,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-hummingboard-emmc-som-v15.dtb \
imx6q-hummingboard-som-v15.dtb \
imx6q-hummingboard2.dtb \
+ imx6q-hummingboard2-som-v15.dtb \
imx6q-icore.dtb \
imx6q-icore-ofcap10.dtb \
imx6q-icore-ofcap12.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-hummingboard2-som-v15.dts b/arch/arm/boot/dts/imx6dl-hummingboard2-som-v15.dts
new file mode 100644
index 000000000000..e61ef1156f8b
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-hummingboard2-som-v15.dts
@@ -0,0 +1,54 @@
+/*
+ * Device Tree file for SolidRun HummingBoard2
+ * Copyright (C) 2015 Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
+ * Based on work by Russell King
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-sr-som.dtsi"
+#include "imx6qdl-sr-som-ti.dtsi"
+#include "imx6qdl-hummingboard2.dtsi"
+
+/ {
+ model = "SolidRun HummingBoard2 Solo/DualLite (1.5som)";
+ compatible = "solidrun,hummingboard2/dl", "fsl,imx6dl";
+};
diff --git a/arch/arm/boot/dts/imx6q-hummingboard2-som-v15.dts b/arch/arm/boot/dts/imx6q-hummingboard2-som-v15.dts
new file mode 100644
index 000000000000..d3ad7329cd6d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-hummingboard2-som-v15.dts
@@ -0,0 +1,62 @@
+/*
+ * Device Tree file for SolidRun HummingBoard2
+ * Copyright (C) 2015 Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
+ * Based on work by Russell King
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-sr-som.dtsi"
+#include "imx6qdl-sr-som-ti.dtsi"
+#include "imx6qdl-hummingboard2.dtsi"
+
+/ {
+ model = "SolidRun HummingBoard2 Dual/Quad (1.5som)";
+ compatible = "solidrun,hummingboard2/q", "fsl,imx6q";
+};
+
+&sata {
+ status = "okay";
+ fsl,transmit-level-mV = <1104>;
+ fsl,transmit-boost-mdB = <0>;
+ fsl,transmit-atten-16ths = <9>;
+ fsl,no-spread-spectrum;
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 17/20] ARM: dts: imx6qdl-hummingboard2: add PWM3 support
From: Russell King @ 2017-12-11 16:58 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 6954d4875cd8..1089f693ebde 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -361,6 +361,12 @@
>;
};
+ pinctrl_hummingboard2_pwm3: pwm3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
+ >;
+ };
+
pinctrl_hummingboard2_sgtl5000: hummingboard2-sgtl5000 {
fsl,pins = <
MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x130b0
@@ -463,6 +469,12 @@
status = "okay";
};
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_pwm3>;
+ status = "okay";
+};
+
&ssi1 {
status = "okay";
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 16/20] ARM: dts: imx6*-hummingboard2: split out eMMC support
From: Russell King @ 2017-12-11 16:58 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
eMMC is optional on HB2 boards, and may be implemented by the SOM. Move
it out of the base HB2 include file.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/imx6dl-hummingboard2.dts | 1 +
arch/arm/boot/dts/imx6q-hummingboard2.dts | 1 +
arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi | 72 +++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 26 --------
4 files changed, 74 insertions(+), 26 deletions(-)
create mode 100644 arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi
diff --git a/arch/arm/boot/dts/imx6dl-hummingboard2.dts b/arch/arm/boot/dts/imx6dl-hummingboard2.dts
index 99b6cce13175..b12cd87f3f94 100644
--- a/arch/arm/boot/dts/imx6dl-hummingboard2.dts
+++ b/arch/arm/boot/dts/imx6dl-hummingboard2.dts
@@ -45,6 +45,7 @@
#include "imx6qdl-sr-som.dtsi"
#include "imx6qdl-sr-som-brcm.dtsi"
#include "imx6qdl-hummingboard2.dtsi"
+#include "imx6qdl-hummingboard2-emmc.dtsi"
/ {
model = "SolidRun HummingBoard2 Solo/DualLite";
diff --git a/arch/arm/boot/dts/imx6q-hummingboard2.dts b/arch/arm/boot/dts/imx6q-hummingboard2.dts
index fab388a0f673..5249f53dcdbc 100644
--- a/arch/arm/boot/dts/imx6q-hummingboard2.dts
+++ b/arch/arm/boot/dts/imx6q-hummingboard2.dts
@@ -45,6 +45,7 @@
#include "imx6qdl-sr-som.dtsi"
#include "imx6qdl-sr-som-brcm.dtsi"
#include "imx6qdl-hummingboard2.dtsi"
+#include "imx6qdl-hummingboard2-emmc.dtsi"
/ {
model = "SolidRun HummingBoard2 Dual/Quad";
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi
new file mode 100644
index 000000000000..1aa97817e751
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi
@@ -0,0 +1,72 @@
+/*
+ * Device Tree file for SolidRun HummingBoard2
+ * Copyright (C) 2015 Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+&iomuxc {
+ hummingboard2 {
+ pinctrl_hummingboard2_usdhc3: hummingboard2-usdhc3 {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
+ >;
+ };
+ };
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_usdhc3>;
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_3p3v>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 52ed580cf64a..6954d4875cd8 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -441,22 +441,6 @@
>;
};
- pinctrl_hummingboard2_usdhc3: hummingboard2-usdhc3 {
- fsl,pins = <
- MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
- MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
- MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
- MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
- MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
- MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
- MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
- MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
- MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
- MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
- MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
- >;
- };
-
pinctrl_hummingboard2_uart3: hummingboard2-uart3 {
fsl,pins = <
MX6QDL_PAD_EIM_D25__UART3_TX_DATA 0x1b0b1
@@ -515,16 +499,6 @@
status = "okay";
};
-&usdhc3 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_hummingboard2_usdhc3>;
- vmmc-supply = <®_3p3v>;
- vqmmc-supply = <®_3p3v>;
- bus-width = <8>;
- non-removable;
- status = "okay";
-};
-
&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_uart3>;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 15/20] ARM: dts: imx6*-hummingboard2: rework regulators
From: Russell King @ 2017-12-11 16:58 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
From: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Name the regulators according to the voltage rails they are feeding in
the schematic. The USB 2-4 regulators are fixed regulators and are always
on, as they are not a VBUS supply for a single USB host port on the i.MX6,
but supply VBUS to ports behind a USB hub and there is currently no way
to model this in mainline.
Signed-off-by: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 6fbfa970a0a7..52ed580cf64a 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -54,7 +54,7 @@
reg_3p3v: regulator-3p3v {
compatible = "regulator-fixed";
- regulator-name = "3P3V";
+ regulator-name = "VCC_3V2";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
@@ -62,7 +62,7 @@
reg_1p8v: regulator-1p8v {
compatible = "regulator-fixed";
- regulator-name = "1P8V";
+ regulator-name = "VCC_1V8";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
@@ -80,15 +80,16 @@
startup-delay-us = <1000>;
};
- reg_usbh1_vbus: regulator-usb-h1-vbus {
+ reg_usbh2_vbus: regulator-usb-h1-vbus {
compatible = "regulator-fixed";
enable-active-high;
gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usbh1_vbus>;
- regulator-name = "usb_h1_vbus";
+ regulator-name = "V_USB2";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
+ regulator-always-on;
};
reg_usbotg_vbus: regulator-usb-otg-vbus {
@@ -97,33 +98,33 @@
gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usbotg_vbus>;
- regulator-name = "usb_otg_vbus";
+ regulator-name = "V_USB1";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
};
- reg_usbh2_vbus: regulator-usb-h2-vbus {
- compatible = "regulator-gpio";
+ reg_usbh3_vbus: regulator-usb-h2-vbus {
+ compatible = "regulator-fixed";
enable-active-high;
enable-gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usbh2_vbus>;
- regulator-name = "usb_h2_vbus";
+ regulator-name = "V_USB3";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
- regulator-boot-on;
+ regulator-always-on;
};
- reg_usbh3_vbus: regulator-usb-h3-vbus {
- compatible = "regulator-gpio";
+ reg_usbh4_vbus: regulator-usb-h3-vbus {
+ compatible = "regulator-fixed";
enable-active-high;
enable-gpio = <&gpio7 10 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usbh3_vbus>;
- regulator-name = "usb_h3_vbus";
+ regulator-name = "V_USB4";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
- regulator-boot-on;
+ regulator-always-on;
};
sound-sgtl5000 {
@@ -484,7 +485,6 @@
&usbh1 {
disable-over-current;
- vbus-supply = <®_usbh1_vbus>;
status = "okay";
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 14/20] ARM: dts: imx6*-hummingboard2: remove redundant PWM disables
From: Russell King @ 2017-12-11 16:58 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
From: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
The PWM nodes are already disabled in the imx6qdl.dtsi, so there
is no need to disable them again in the board DTS.
Signed-off-by: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 2a63c992b62c..6fbfa970a0a7 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -478,14 +478,6 @@
status = "okay";
};
-&pwm3 {
- status = "disabled";
-};
-
-&pwm4 {
- status = "disabled";
-};
-
&ssi1 {
status = "okay";
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 13/20] ARM: dts: imx6*-hummingboard2: remove non-mainline property from RTC
From: Russell King @ 2017-12-11 16:58 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
From: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Signed-off-by: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 9d5c3b2d3494..2a63c992b62c 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -167,7 +167,6 @@
pcf8523: rtc@68 {
compatible = "nxp,pcf8523";
reg = <0x68>;
- nxp,12p5_pf;
};
sgtl5000: codec@0a {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 12/20] ARM: dts: imx6*-hummingboard2: fix PCIe reset polarity
From: Russell King @ 2017-12-11 16:58 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
From: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
The driver always uses active-low, but better describe reality in the DT.
Signed-off-by: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 4ddc4b73b9ae..9d5c3b2d3494 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -469,7 +469,7 @@
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_pcie_reset>;
- reset-gpio = <&gpio2 11 0>;
+ reset-gpio = <&gpio2 11 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 11/20] ARM: dts: imx6*-hummingboard2: remove LDB node
From: Russell King @ 2017-12-11 16:58 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
From: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
It's disabled by default and the data mapping is supposed to be
retrieved from the attached panel driver in mainline.
Signed-off-by: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index dfbcdf33b84c..4ddc4b73b9ae 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -466,15 +466,6 @@
};
};
-&ldb {
- status = "disabled";
-
- lvds-channel@0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
- };
-};
-
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_pcie_reset>;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 10/20] ARM: dts: imx6*-hummingboard2: add SGTL5000 VDDD supply
From: Russell King @ 2017-12-11 16:58 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
From: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
VDDD is supplied by VCC_1P8 on HB2.
Signed-off-by: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index ab809ee0c58c..dfbcdf33b84c 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -178,6 +178,7 @@
reg = <0x0a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
+ VDDD-supply = <®_1p8v>;
};
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 09/20] ARM: dts: imx6*-hummingboard2: fix formatting
From: Russell King @ 2017-12-11 16:58 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
From: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Trivial formatting change.
Signed-off-by: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 7e94548c0de7..ab809ee0c58c 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -482,9 +482,9 @@
};
&pwm1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_hummingboard2_pwm1>;
- status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_pwm1>;
+ status = "okay";
};
&pwm3 {
@@ -534,9 +534,7 @@
&usdhc3 {
pinctrl-names = "default";
- pinctrl-0 = <
- &pinctrl_hummingboard2_usdhc3
- >;
+ pinctrl-0 = <&pinctrl_hummingboard2_usdhc3>;
vmmc-supply = <®_3p3v>;
vqmmc-supply = <®_3p3v>;
bus-width = <8>;
--
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
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