* [PATCH v4 2/2] ARM: sama5_defconfig: add support for the Axentia TSE-850 board
From: Peter Rosin @ 2017-01-09 8:45 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
Nicolas Ferre, Alexandre Belloni,
Jean-Christophe Plagniol-Villard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483951529-11738-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
---
arch/arm/configs/sama5_defconfig | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index aca8625b6fc9..bf5b3a73e38c 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -131,7 +131,7 @@ CONFIG_GPIO_SYSFS=y
CONFIG_POWER_SUPPLY=y
CONFIG_BATTERY_ACT8945A=y
CONFIG_POWER_RESET=y
-# CONFIG_HWMON is not set
+CONFIG_SENSORS_JC42=y
CONFIG_WATCHDOG=y
CONFIG_AT91SAM9X_WATCHDOG=y
CONFIG_SAMA5D4_WATCHDOG=y
@@ -142,6 +142,7 @@ CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_ACT8865=y
CONFIG_REGULATOR_ACT8945A=y
+CONFIG_REGULATOR_PWM=y
CONFIG_MEDIA_SUPPORT=y
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_V4L_PLATFORM_DRIVERS=y
@@ -164,6 +165,7 @@ CONFIG_SND_ATMEL_SOC=y
CONFIG_SND_ATMEL_SOC_WM8904=y
# CONFIG_HID_GENERIC is not set
CONFIG_SND_ATMEL_SOC_PDMIC=y
+CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=y
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_EHCI_HCD=y
@@ -199,6 +201,9 @@ CONFIG_AT_XDMAC=y
CONFIG_IIO=y
CONFIG_AT91_ADC=y
CONFIG_AT91_SAMA5D2_ADC=y
+CONFIG_ENVELOPE_DETECTOR=y
+CONFIG_DPOT_DAC=y
+CONFIG_MCP4531=y
CONFIG_PWM=y
CONFIG_PWM_ATMEL=y
CONFIG_PWM_ATMEL_HLCDC_PWM=y
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/4] ARM: dts: move hdmi pinctrl out of board file.
From: Archit Taneja @ 2017-01-09 8:52 UTC (permalink / raw)
To: Srinivas Kandagatla, Andy Gross
Cc: David Brown, Rob Herring, Mark Rutland, linux-arm-msm, linux-soc,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1483536854-21389-1-git-send-email-srinivas.kandagatla@linaro.org>
On 01/04/2017 07:04 PM, Srinivas Kandagatla wrote:
> This patch moves hdmi pinctrl defination from board file to soc level
> pinctrl file. If not this pinctrl setup will be duplicated across all
> the apq8064 based board files.
Reviewed-by: Archit Taneja <architt@codeaurora.org>
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 22 ----------------------
> arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 19 +++++++++++++++++++
> arch/arm/boot/dts/qcom-apq8064.dtsi | 2 ++
> 3 files changed, 21 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> index 3d37cab..881ce70 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> @@ -75,25 +75,6 @@
> bias-disable;
> };
> };
> -
> - hdmi_pinctrl: hdmi-pinctrl {
> - mux {
> - pins = "gpio70", "gpio71", "gpio72";
> - function = "hdmi";
> - };
> -
> - pinconf_ddc {
> - pins = "gpio70", "gpio71";
> - bias-pull-up;
> - drive-strength = <2>;
> - };
> -
> - pinconf_hpd {
> - pins = "gpio72";
> - bias-pull-down;
> - drive-strength = <16>;
> - };
> - };
> };
>
> rpm@108000 {
> @@ -368,9 +349,6 @@
>
> hpd-gpios = <&tlmm_pinmux 72 GPIO_ACTIVE_HIGH>;
>
> - pinctrl-names = "default";
> - pinctrl-0 = <&hdmi_pinctrl>;
> -
> ports {
> port@0 {
> endpoint {
> diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
> index 6b801e7..cba4450 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
> @@ -284,4 +284,23 @@
> bias-disable = <0>;
> };
> };
> +
> + hdmi_pinctrl: hdmi-pinctrl {
> + mux {
> + pins = "gpio70", "gpio71", "gpio72";
> + function = "hdmi";
> + };
> +
> + pinconf_ddc {
> + pins = "gpio70", "gpio71";
> + bias-pull-up;
> + drive-strength = <2>;
> + };
> +
> + pinconf_hpd {
> + pins = "gpio72";
> + bias-pull-down;
> + drive-strength = <16>;
> + };
> + };
> };
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 407a461..e68a8a1 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -1327,6 +1327,8 @@
>
> hdmi: hdmi-tx@4a00000 {
> compatible = "qcom,hdmi-tx-8960";
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_pinctrl>;
> reg = <0x04a00000 0x2f0>;
> reg-names = "core_physical";
> interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 2/4] ARM: dts: sd-600eval: add hdmi support
From: Archit Taneja @ 2017-01-09 8:52 UTC (permalink / raw)
To: Srinivas Kandagatla, Andy Gross
Cc: David Brown, Rob Herring, Mark Rutland,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483536854-21389-2-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 01/04/2017 07:04 PM, Srinivas Kandagatla wrote:
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Archit Taneja <architt-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> .../arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts | 44 ++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts b/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
> index 39ae2bc..4e908af 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
> @@ -39,6 +39,17 @@
>
> };
>
> + hdmi-out {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con: endpoint {
> + remote-endpoint = <&hdmi_out>;
> + };
> + };
> + };
> +
> soc {
> rpm@108000 {
> regulators {
> @@ -347,5 +358,38 @@
> cd-gpios = <&tlmm_pinmux 26 GPIO_ACTIVE_HIGH>;
> };
> };
> +
> + hdmi-tx@4a00000 {
> + status = "okay";
> + core-vdda-supply = <&pm8921_hdmi_switch>;
> + hdmi-mux-supply = <&vcc3v3>;
> +
> + hpd-gpio = <&tlmm_pinmux 72 GPIO_ACTIVE_HIGH>;
> +
> + ports {
> + port@1 {
> + endpoint {
> + remote-endpoint = <&hdmi_con>;
> + };
> + };
> + };
> + };
> +
> + hdmi-phy@4a00400 {
> + status = "okay";
> + core-vdda-supply = <&pm8921_hdmi_switch>;
> + };
> +
> + mdp@5100000 {
> + status = "okay";
> +
> + ports {
> + port@3 {
> + endpoint {
> + remote-endpoint = <&hdmi_in>;
> + };
> + };
> + };
> + };
> };
> };
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/6] arm64: dts: apq8016-sbc: add support to hdmi audio via adv7533
From: Archit Taneja @ 2017-01-09 8:53 UTC (permalink / raw)
To: Srinivas Kandagatla, Andy Gross
Cc: David Brown, Rob Herring, Mark Rutland, linux-arm-msm, linux-soc,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1483536902-21450-3-git-send-email-srinivas.kandagatla@linaro.org>
On 01/04/2017 07:04 PM, Srinivas Kandagatla wrote:
> This patch adds support to hdmi audio via adv7533.
Tested-by: Archit Taneja <architt@codeaurora.org>
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 08bd5eb..5ab277f 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -85,6 +85,7 @@
> pinctrl-names = "default","sleep";
> pinctrl-0 = <&adv7533_int_active &adv7533_switch_active>;
> pinctrl-1 = <&adv7533_int_suspend &adv7533_switch_suspend>;
> + #sound-dai-cells = <1>;
>
> ports {
> #address-cells = <1>;
> @@ -285,6 +286,15 @@
> qcom,audio-routing =
> "AMIC2", "MIC BIAS Internal2",
> "AMIC3", "MIC BIAS External1";
> + external-dai-link@0 {
> + link-name = "ADV7533";
> + cpu { /* QUAT */
> + sound-dai = <&lpass MI2S_QUATERNARY>;
> + };
> + codec {
> + sound-dai = <&adv_bridge 0>;
> + };
> + };
>
> internal-codec-playback-dai-link@0 { /* I2S - Internal codec */
> link-name = "WCD";
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Johannes Berg @ 2017-01-09 8:58 UTC (permalink / raw)
To: Rafał Miłecki, Arend Van Spriel
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rob Herring, Rafał Miłecki
In-Reply-To: <CACna6rxS-JqyW3cXFMJR6Lp-+HdJjZfkwsVRMPGn5Q1z8av75w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sat, 2017-01-07 at 13:58 +0100, Rafał Miłecki wrote:
> > I indeed prefer to talk about the driver instead of we. Indeed it
> > is true due to the orig_flags behavior although that only seems to
> > involve regulatory code. Could it be that brcmfmac undo that
> > through the notifier?
>
> I guess you could touch orig_flags, but I don't know if it's
> preferred way. This is probably question to Johannes & cfg80211 guys.
Right now - before the OF patch - there can't really be any orig_flags
with DISABLED since the driver doesn't set flags to DISABLED before
registering, does it? While registering, flags are copied to orig_flags
so the driver can register with flags like DFS or NO_IR already enabled
- say the firmware requires that - and they will never be overwritten
by cfg80211.
Arguably, what the driver does today - before OF - isn't incorrect
either, since it simply doesn't care about anything it registered with
at all.
However, with the OF, I argued (succesfully it seems :P) that the
sensible thing to do was to register with the DISABLED flag and thereby
"permanently" disable the channels that OF didn't think were usable,
but in this case now the driver has to adhere to the cfg80211 logic of
preserving orig_flags forever.
johannes
^ permalink raw reply
* [PATCH v3 0/5] i2c: mux: pca954x: Add interrupt controller support
From: Phil Reid @ 2017-01-09 9:02 UTC (permalink / raw)
To: peda-koto5C5qi+TLoDKTGw+V6w, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Various muxes can aggregate multiple interrupts from each i2c bus.
All of the muxes with interrupt support combine the active low irq lines
using an internal 'and' function and generate a combined active low
output. The muxes do provide the ability to read a control register to
determine which irq is active. By making the mux an irq controller isr
latenct can potentially be reduced by reading the status register and
then only calling the registered isr on that bus segment.
In addition an additional enable mask is added to work around devices
that assert irq immediately before being setup buy disabling the irq
from the mux until all devices are registered.
Changes from v2:
- p1: Added Acked-by
- p5: fixup 2 typos
Changes from v1:
- Update for new ACPI table
- Fix typo in documentation
- Fix typo in function names
- Fix typo in irq name
- Added spaces around '+' / '='
- Change goto label names
- Change property name from i2c-mux-irq-mask-en to nxp,irq-mask-enable
- Change variable name irq_mask_en to irq_mask_enable
- Add commentt about irq_mask_enable
- Added Acked-By's
Phil Reid (5):
i2c: mux: pca954x: Add missing pca9542 definition to chip_desc
dt: bindings: i2c-mux-pca954x: Add documentation for interrupt
controller
i2c: mux: pca954x: Add interrupt controller support
dt: bindings: i2c-mux-pca954x: Add documentation for
i2c-mux-irq-mask-en
i2c: mux: pca954x: Add irq_mask_en to delay enabling irqs
.../devicetree/bindings/i2c/i2c-mux-pca954x.txt | 17 ++-
drivers/i2c/muxes/i2c-mux-pca954x.c | 156 ++++++++++++++++++++-
2 files changed, 168 insertions(+), 5 deletions(-)
--
1.8.3.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
* [PATCH v3 1/5] i2c: mux: pca954x: Add missing pca9542 definition to chip_desc
From: Phil Reid @ 2017-01-09 9:02 UTC (permalink / raw)
To: peda, wsa, robh+dt, mark.rutland, preid, linux-i2c, devicetree
In-Reply-To: <1483952576-5308-1-git-send-email-preid@electromag.com.au>
The spec for the pca954x was missing. This chip is the same as the pca9540
except that it has interrupt lines. While the i2c_device_id table mapped
the pca9542 to the pca9540 definition the compatible table did not. In
preparation for irq support add the pca9542 definition.
Acked-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
index dd18b9c..bbf088e 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -84,6 +84,11 @@ struct pca954x {
.enable = 0x4,
.muxtype = pca954x_ismux,
},
+ [pca_9542] = {
+ .nchans = 2,
+ .enable = 0x4,
+ .muxtype = pca954x_ismux,
+ },
[pca_9543] = {
.nchans = 2,
.muxtype = pca954x_isswi,
@@ -110,7 +115,7 @@ struct pca954x {
static const struct i2c_device_id pca954x_id[] = {
{ "pca9540", pca_9540 },
- { "pca9542", pca_9540 },
+ { "pca9542", pca_9542 },
{ "pca9543", pca_9543 },
{ "pca9544", pca_9544 },
{ "pca9545", pca_9545 },
@@ -124,7 +129,7 @@ struct pca954x {
#ifdef CONFIG_ACPI
static const struct acpi_device_id pca954x_acpi_ids[] = {
{ .id = "PCA9540", .driver_data = pca_9540 },
- { .id = "PCA9542", .driver_data = pca_9540 },
+ { .id = "PCA9542", .driver_data = pca_9542 },
{ .id = "PCA9543", .driver_data = pca_9543 },
{ .id = "PCA9544", .driver_data = pca_9544 },
{ .id = "PCA9545", .driver_data = pca_9545 },
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 2/5] dt: bindings: i2c-mux-pca954x: Add documentation for interrupt controller
From: Phil Reid @ 2017-01-09 9:02 UTC (permalink / raw)
To: peda, wsa, robh+dt, mark.rutland, preid, linux-i2c, devicetree
In-Reply-To: <1483952576-5308-1-git-send-email-preid@electromag.com.au>
Various muxes can aggregate multiple irq lines and provide a control
register to determine the active line. Add bindings for interrupt
controller support.
Acked-by: Peter Rosin <peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
index cf53d5f..aa09704 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
@@ -19,7 +19,14 @@ Optional Properties:
- i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
children in idle state. This is necessary for example, if there are several
multiplexers on the bus and the devices behind them use same I2C addresses.
-
+ - interrupt-parent: Phandle for the interrupt controller that services
+ interrupts for this device.
+ - interrupts: Interrupt mapping for IRQ.
+ - interrupt-controller: Marks the device node as an interrupt controller.
+ - #interrupt-cells : Should be two.
+ - first cell is the pin number
+ - second cell is used to specify flags.
+ See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
Example:
@@ -29,6 +36,11 @@ Example:
#size-cells = <0>;
reg = <0x74>;
+ interrupt-parent = <&ipic>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 3/5] i2c: mux: pca954x: Add interrupt controller support
From: Phil Reid @ 2017-01-09 9:02 UTC (permalink / raw)
To: peda, wsa, robh+dt, mark.rutland, preid, linux-i2c, devicetree
In-Reply-To: <1483952576-5308-1-git-send-email-preid@electromag.com.au>
Various muxes can aggregate multiple interrupts from each i2c bus.
All of the muxes with interrupt support combine the active low irq lines
using an internal 'and' function and generate a combined active low
output. The muxes do provide the ability to read a control register to
determine which irq is active. By making the mux an irq controller isr
latency can potentially be reduced by reading the status register and
then only calling the registered isr on that bus segment.
As there is no irq masking on the mux irq are disabled until irq_unmask is
called at least once.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 127 +++++++++++++++++++++++++++++++++++-
1 file changed, 125 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
index bbf088e..84fc767 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -41,14 +41,19 @@
#include <linux/i2c.h>
#include <linux/i2c-mux.h>
#include <linux/i2c/pca954x.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_irq.h>
#include <linux/pm.h>
#include <linux/slab.h>
#define PCA954X_MAX_NCHANS 8
+#define PCA954X_IRQ_OFFSET 4
+
enum pca_type {
pca_9540,
pca_9542,
@@ -63,6 +68,7 @@ enum pca_type {
struct chip_desc {
u8 nchans;
u8 enable; /* used for muxes only */
+ u8 has_irq;
enum muxtype {
pca954x_ismux = 0,
pca954x_isswi
@@ -75,6 +81,9 @@ struct pca954x {
u8 last_chan; /* last register value */
u8 deselect;
struct i2c_client *client;
+
+ struct irq_domain *irq;
+ unsigned int irq_mask;
};
/* Provide specs for the PCA954x types we know about */
@@ -87,19 +96,23 @@ struct pca954x {
[pca_9542] = {
.nchans = 2,
.enable = 0x4,
+ .has_irq = 1,
.muxtype = pca954x_ismux,
},
[pca_9543] = {
.nchans = 2,
+ .has_irq = 1,
.muxtype = pca954x_isswi,
},
[pca_9544] = {
.nchans = 4,
.enable = 0x4,
+ .has_irq = 1,
.muxtype = pca954x_ismux,
},
[pca_9545] = {
.nchans = 4,
+ .has_irq = 1,
.muxtype = pca954x_isswi,
},
[pca_9547] = {
@@ -222,6 +235,102 @@ static int pca954x_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
return pca954x_reg_write(muxc->parent, client, data->last_chan);
}
+static irqreturn_t pca954x_irq_handler(int irq, void *dev_id)
+{
+ struct pca954x *data = dev_id;
+ unsigned int child_irq;
+ int ret, i, handled;
+
+ ret = i2c_smbus_read_byte(data->client);
+ if (ret < 0)
+ return IRQ_NONE;
+
+ for (i = 0; i < data->chip->nchans; i++) {
+ if (ret & BIT(PCA954X_IRQ_OFFSET + i)) {
+ child_irq = irq_linear_revmap(data->irq, i);
+ handle_nested_irq(child_irq);
+ handled++;
+ }
+ }
+ return handled ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static void pca954x_irq_mask(struct irq_data *idata)
+{
+ struct pca954x *data = irq_data_get_irq_chip_data(idata);
+ unsigned int pos = idata->hwirq;
+
+ data->irq_mask &= ~BIT(pos);
+ if (!data->irq_mask)
+ disable_irq(data->client->irq);
+}
+
+static void pca954x_irq_unmask(struct irq_data *idata)
+{
+ struct pca954x *data = irq_data_get_irq_chip_data(idata);
+ unsigned int pos = idata->hwirq;
+
+ if (!data->irq_mask)
+ enable_irq(data->client->irq);
+ data->irq_mask |= BIT(pos);
+}
+
+static int pca954x_irq_set_type(struct irq_data *idata, unsigned int type)
+{
+ if ((type & IRQ_TYPE_SENSE_MASK) != IRQ_TYPE_LEVEL_LOW)
+ return -EINVAL;
+ return 0;
+}
+
+static struct irq_chip pca954x_irq_chip = {
+ .name = "i2c-mux-pca954x",
+ .irq_mask = pca954x_irq_mask,
+ .irq_unmask = pca954x_irq_unmask,
+ .irq_set_type = pca954x_irq_set_type,
+};
+
+static int pca954x_irq_setup(struct i2c_mux_core *muxc)
+{
+ struct pca954x *data = i2c_mux_priv(muxc);
+ struct i2c_client *client = data->client;
+ int c, err, irq;
+
+ if (!data->chip->has_irq || client->irq <= 0)
+ return 0;
+
+ data->irq = irq_domain_add_linear(client->dev.of_node,
+ data->chip->nchans,
+ &irq_domain_simple_ops, data);
+ if (!data->irq)
+ return -ENODEV;
+
+ for (c = 0; c < data->chip->nchans; c++) {
+ irq = irq_create_mapping(data->irq, c);
+ irq_set_chip_data(irq, data);
+ irq_set_chip_and_handler(irq, &pca954x_irq_chip,
+ handle_simple_irq);
+ }
+
+ err = devm_request_threaded_irq(&client->dev, data->client->irq, NULL,
+ pca954x_irq_handler,
+ IRQF_ONESHOT | IRQF_SHARED,
+ "pca954x", data);
+ if (err)
+ goto err_req_irq;
+
+ disable_irq(data->client->irq);
+
+ return 0;
+err_req_irq:
+ for (c = 0; c < data->chip->nchans; c++) {
+ irq = irq_find_mapping(data->irq, c);
+ irq_dispose_mapping(irq);
+ }
+ irq_domain_remove(data->irq);
+
+ return err;
+}
+
/*
* I2C init/probing/exit functions
*/
@@ -286,6 +395,10 @@ static int pca954x_probe(struct i2c_client *client,
idle_disconnect_dt = of_node &&
of_property_read_bool(of_node, "i2c-mux-idle-disconnect");
+ ret = pca954x_irq_setup(muxc);
+ if (ret)
+ goto fail_del_adapters;
+
/* Now create an adapter for each channel */
for (num = 0; num < data->chip->nchans; num++) {
bool idle_disconnect_pd = false;
@@ -311,7 +424,7 @@ static int pca954x_probe(struct i2c_client *client,
dev_err(&client->dev,
"failed to register multiplexed adapter"
" %d as bus %d\n", num, force);
- goto virt_reg_failed;
+ goto fail_del_adapters;
}
}
@@ -322,7 +435,7 @@ static int pca954x_probe(struct i2c_client *client,
return 0;
-virt_reg_failed:
+fail_del_adapters:
i2c_mux_del_adapters(muxc);
return ret;
}
@@ -330,6 +443,16 @@ static int pca954x_probe(struct i2c_client *client,
static int pca954x_remove(struct i2c_client *client)
{
struct i2c_mux_core *muxc = i2c_get_clientdata(client);
+ struct pca954x *data = i2c_mux_priv(muxc);
+ int c, irq;
+
+ if (data->irq) {
+ for (c = 0; c < data->chip->nchans; c++) {
+ irq = irq_find_mapping(data->irq, c);
+ irq_dispose_mapping(irq);
+ }
+ irq_domain_remove(data->irq);
+ }
i2c_mux_del_adapters(muxc);
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 4/5] dt: bindings: i2c-mux-pca954x: Add documentation for i2c-mux-irq-mask-en
From: Phil Reid @ 2017-01-09 9:02 UTC (permalink / raw)
To: peda-koto5C5qi+TLoDKTGw+V6w, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483952576-5308-1-git-send-email-preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
Unfortunately some hardware device will assert their irq line immediately
on power on and provide no mechanism to mask the irq. As the i2c muxes
provide no method to mask irq line this provides a work around by keeping
the parent irq masked until enough device drivers have loaded to service
all pending interrupts.
For example the the ltc1760 assert its SMBALERT irq immediately on power
on. With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
device is registered irq are enabled and fire continuously as the second
device driver has not yet loaded. Setting this parameter to 0x3 while
delay the irq being enabled until both devices are ready.
Acked-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
---
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
index aa09704..6de1e8e 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
@@ -19,6 +19,8 @@ Optional Properties:
- i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
children in idle state. This is necessary for example, if there are several
multiplexers on the bus and the devices behind them use same I2C addresses.
+ - nxp,irq-mask-enable: BitMask; Defines a mask for which irq lines need to be
+ unmasked before the parent irq line in enabled.
- interrupt-parent: Phandle for the interrupt controller that services
interrupts for this device.
- interrupts: Interrupt mapping for IRQ.
@@ -36,6 +38,7 @@ Example:
#size-cells = <0>;
reg = <0x74>;
+ nxp,irq-mask-enable = <0x3>;
interrupt-parent = <&ipic>;
interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
--
1.8.3.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
* [PATCH v3 5/5] i2c: mux: pca954x: Add irq_mask_en to delay enabling irqs
From: Phil Reid @ 2017-01-09 9:02 UTC (permalink / raw)
To: peda-koto5C5qi+TLoDKTGw+V6w, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483952576-5308-1-git-send-email-preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
Unfortunately some hardware device will assert their irq line immediately
on power on and provide no mechanism to mask the irq. As the i2c muxes
provide no method to mask irq line this provides a work around by keeping
the parent irq masked until enough device drivers have loaded to service
all pending interrupts.
For example the the ltc1760 assert its SMBALERT irq immediately on power
on. With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
device is registered irq are enabled and fire continuously as the second
device driver has not yet loaded. Setting this parameter to 0x3 while
delay the irq being enabled until both devices are ready.
Acked-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
index 84fc767..fb1d245 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -75,6 +75,19 @@ struct chip_desc {
} muxtype;
};
+/*
+ * irq_mask_enable: Provides a mechanism to work around hardware that asserts
+ * their irq immediately on power on. It allows the enabling of the irq to be
+ * delayed until the corresponding bits in the the irq_mask are set thru
+ * irq_unmask.
+ * For example the ltc1760 assert its SMBALERT irq immediately on power on.
+ * With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
+ * device is registered irq are enabled and fire continuously as the second
+ * device driver has not yet loaded. Setting this parameter to 0x3 while
+ * delay the irq being enabled until both devices are ready.
+ * This workaround will not work if two devices share an interrupt on the
+ * same bus segment.
+ */
struct pca954x {
const struct chip_desc *chip;
@@ -84,6 +97,7 @@ struct pca954x {
struct irq_domain *irq;
unsigned int irq_mask;
+ unsigned int irq_mask_enable;
};
/* Provide specs for the PCA954x types we know about */
@@ -270,9 +284,12 @@ static void pca954x_irq_unmask(struct irq_data *idata)
struct pca954x *data = irq_data_get_irq_chip_data(idata);
unsigned int pos = idata->hwirq;
- if (!data->irq_mask)
+ if (!data->irq_mask_enable && !data->irq_mask)
enable_irq(data->client->irq);
data->irq_mask |= BIT(pos);
+ if (data->irq_mask_enable &&
+ (data->irq_mask & data->irq_mask) == data->irq_mask_enable)
+ enable_irq(data->client->irq);
}
static int pca954x_irq_set_type(struct irq_data *idata, unsigned int type)
@@ -395,6 +412,9 @@ static int pca954x_probe(struct i2c_client *client,
idle_disconnect_dt = of_node &&
of_property_read_bool(of_node, "i2c-mux-idle-disconnect");
+ of_property_read_u32(of_node, "nxp,irq-mask-enable",
+ &data->irq_mask_enable);
+
ret = pca954x_irq_setup(muxc);
if (ret)
goto fail_del_adapters;
--
1.8.3.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 v2 5/5] i2c: mux: pca954x: Add irq_mask_en to delay enabling irqs
From: Phil Reid @ 2017-01-09 9:04 UTC (permalink / raw)
To: Peter Rosin, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <c5b2eeef-4501-e866-4bb3-f02ada7d4604-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 9/01/2017 15:54, Peter Rosin wrote:
> On 2017-01-05 05:11, Phil Reid wrote:
>> Unfortunately some hardware device will assert their irq line immediately
>> on power on and provide no mechanism to mask the irq. As the i2c muxes
>> provide no method to mask irq line this provides a work around by keeping
>> the parent irq masked until enough device drivers have loaded to service
>> all pending interrupts.
>>
>> For example the the ltc1760 assert its SMBALERT irq immediately on power
>> on. With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
>> device is registered irq are enabled and fire continuously as the second
>> device driver has not yet loaded. Setting this parameter to 0x3 while
>> delay the irq being enabled until both devices are ready.
>>
>> Acked-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>
> Ooops, too soon apparently, but the below nitpicks are not that important.
> Maybe Wolfram can fix it up instead of you sending a new version?
G'day Peter,
I've done a v3 with those changes. And added your ack to p1.
Regards
Phil
>
> Cheers,
> peda
>
>> Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
>> ---
>> drivers/i2c/muxes/i2c-mux-pca954x.c | 22 +++++++++++++++++++++-
>> 1 file changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
>> index 84fc767..581a75d 100644
>> --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
>> +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
>> @@ -75,6 +75,19 @@ struct chip_desc {
>> } muxtype;
>> };
>>
>> +/*
>> + * irq_mask_enable: Provides a mechanism to work around hardware that asserts
>> + * their irq immediately on power on. It allows the enabling of the irq to be
>
> double space: "the irq"
>
>> + * delayed until the corresponding bits in the the irq_mask are set thru
>> + * irq_unmask.
>> + * For example the the ltc1760 assert its SMBALERT irq immediately on power
>
> "the the"
>
>> + * on. With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
>> + * device is registered irq are enabled and fire continuously as the second
>> + * device driver has not yet loaded. Setting this parameter to 0x3 while
>> + * delay the irq being enabled until both devices are ready.
>> + * This workaround will not work if two devices share an interrupt on the
>> + * same bus segment.
>> + */
>> struct pca954x {
>> const struct chip_desc *chip;
>>
>> @@ -84,6 +97,7 @@ struct pca954x {
>>
>> struct irq_domain *irq;
>> unsigned int irq_mask;
>> + unsigned int irq_mask_enable;
>> };
>>
>> /* Provide specs for the PCA954x types we know about */
>> @@ -270,9 +284,12 @@ static void pca954x_irq_unmask(struct irq_data *idata)
>> struct pca954x *data = irq_data_get_irq_chip_data(idata);
>> unsigned int pos = idata->hwirq;
>>
>> - if (!data->irq_mask)
>> + if (!data->irq_mask_enable && !data->irq_mask)
>> enable_irq(data->client->irq);
>> data->irq_mask |= BIT(pos);
>> + if (data->irq_mask_enable &&
>> + (data->irq_mask & data->irq_mask) == data->irq_mask_enable)
>> + enable_irq(data->client->irq);
>> }
>>
>> static int pca954x_irq_set_type(struct irq_data *idata, unsigned int type)
>> @@ -395,6 +412,9 @@ static int pca954x_probe(struct i2c_client *client,
>> idle_disconnect_dt = of_node &&
>> of_property_read_bool(of_node, "i2c-mux-idle-disconnect");
>>
>> + of_property_read_u32(of_node, "nxp,irq-mask-enable",
>> + &data->irq_mask_enable);
>> +
>> ret = pca954x_irq_setup(muxc);
>> if (ret)
>> goto fail_del_adapters;
>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 0/3] STM32F4 Clock binding fix & update
From: gabriel.fernandez @ 2017-01-09 9:07 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, daniel.thompson, andrea.merello, radoslaw.pietrzyk
Cc: devicetree, amelie.delaunay, olivier.bideau, linux-kernel,
linux-clk, linux-arm-kernel, gabriel.fernandez, ludovic.barre
From: Gabriel Fernandez <gabriel.fernandez@st.com>
v2:
- Only rename commit subject of first patch to avoid the error:
Remote Server returned '<vger.kernel.org #5.7.1 SMTP;
550 5.7.1 Content-Policy reject msg: The capital Triple-X in subject
is way too often associated with junk email,
This patch-set includes:
- a fix to STM32F4_X_CLOCK() macro
- an update of missing binding definition
- a patch to use STM32F4_X_CLOCK() macro
Gabriel Fernandez (3):
dt-bindings: mfd: stm32f4: Fix STM32F4_X_CLOCK() macro
dt-bindings: mfd: stm32f4: Add missing binding definition
ARM: dts: stm32: Use clock DT binding definition on stm32f429 family
arch/arm/boot/dts/stm32429i-eval.dts | 2 +-
arch/arm/boot/dts/stm32f429.dtsi | 66 +++++++++++++++++++----------------
include/dt-bindings/mfd/stm32f4-rcc.h | 24 +++++++++----
3 files changed, 53 insertions(+), 39 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: mfd: stm32f4: Fix STM32F4_X_CLOCK() macro
From: gabriel.fernandez @ 2017-01-09 9:07 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, daniel.thompson, andrea.merello, radoslaw.pietrzyk
Cc: devicetree, amelie.delaunay, olivier.bideau, linux-kernel,
linux-clk, linux-arm-kernel, gabriel.fernandez, ludovic.barre
In-Reply-To: <1483952833-14704-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
Macro to select a clock was not correct.
Offset of enable register starts at 0x30, then calculation to select a bit is:
(@enable_reg - 0x30) / 4 * 32 + bit_to_select
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
Tested-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
---
include/dt-bindings/mfd/stm32f4-rcc.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
index e98942d..f662b19 100644
--- a/include/dt-bindings/mfd/stm32f4-rcc.h
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -25,7 +25,7 @@
#define STM32F4_RCC_AHB1_OTGHS 29
#define STM32F4_AHB1_RESET(bit) (STM32F4_RCC_AHB1_##bit + (0x10 * 8))
-#define STM32F4_AHB1_CLOCK(bit) (STM32F4_RCC_AHB1_##bit + (0x30 * 8))
+#define STM32F4_AHB1_CLOCK(bit) (STM32F4_RCC_AHB1_##bit)
/* AHB2 */
@@ -36,13 +36,13 @@
#define STM32F4_RCC_AHB2_OTGFS 7
#define STM32F4_AHB2_RESET(bit) (STM32F4_RCC_AHB2_##bit + (0x14 * 8))
-#define STM32F4_AHB2_CLOCK(bit) (STM32F4_RCC_AHB2_##bit + (0x34 * 8))
+#define STM32F4_AHB2_CLOCK(bit) (STM32F4_RCC_AHB2_##bit + 0x20)
/* AHB3 */
#define STM32F4_RCC_AHB3_FMC 0
#define STM32F4_AHB3_RESET(bit) (STM32F4_RCC_AHB3_##bit + (0x18 * 8))
-#define STM32F4_AHB3_CLOCK(bit) (STM32F4_RCC_AHB3_##bit + (0x38 * 8))
+#define STM32F4_AHB3_CLOCK(bit) (STM32F4_RCC_AHB3_##bit + 0x40)
/* APB1 */
#define STM32F4_RCC_APB1_TIM2 0
@@ -72,7 +72,7 @@
#define STM32F4_RCC_APB1_UART8 31
#define STM32F4_APB1_RESET(bit) (STM32F4_RCC_APB1_##bit + (0x20 * 8))
-#define STM32F4_APB1_CLOCK(bit) (STM32F4_RCC_APB1_##bit + (0x40 * 8))
+#define STM32F4_APB1_CLOCK(bit) (STM32F4_RCC_APB1_##bit + 0x80)
/* APB2 */
#define STM32F4_RCC_APB2_TIM1 0
@@ -93,6 +93,6 @@
#define STM32F4_RCC_APB2_LTDC 26
#define STM32F4_APB2_RESET(bit) (STM32F4_RCC_APB2_##bit + (0x24 * 8))
-#define STM32F4_APB2_CLOCK(bit) (STM32F4_RCC_APB2_##bit + (0x44 * 8))
+#define STM32F4_APB2_CLOCK(bit) (STM32F4_RCC_APB2_##bit + 0xA0)
#endif /* _DT_BINDINGS_MFD_STM32F4_RCC_H */
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: mfd: stm32f4: Add missing binding definition
From: gabriel.fernandez @ 2017-01-09 9:07 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, daniel.thompson, andrea.merello, radoslaw.pietrzyk
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-clk,
gabriel.fernandez, ludovic.barre, olivier.bideau, amelie.delaunay
In-Reply-To: <1483952833-14704-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch adds missing binding definition (backupram, ethernet, otg,
qspi, adc & dsi)
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
include/dt-bindings/mfd/stm32f4-rcc.h | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
index f662b19..082a81c 100644
--- a/include/dt-bindings/mfd/stm32f4-rcc.h
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -18,11 +18,17 @@
#define STM32F4_RCC_AHB1_GPIOJ 9
#define STM32F4_RCC_AHB1_GPIOK 10
#define STM32F4_RCC_AHB1_CRC 12
+#define STM32F4_RCC_AHB1_BKPSRAM 18
+#define STM32F4_RCC_AHB1_CCMDATARAM 20
#define STM32F4_RCC_AHB1_DMA1 21
#define STM32F4_RCC_AHB1_DMA2 22
#define STM32F4_RCC_AHB1_DMA2D 23
#define STM32F4_RCC_AHB1_ETHMAC 25
-#define STM32F4_RCC_AHB1_OTGHS 29
+#define STM32F4_RCC_AHB1_ETHMACTX 26
+#define STM32F4_RCC_AHB1_ETHMACRX 27
+#define STM32F4_RCC_AHB1_ETHMACPTP 28
+#define STM32F4_RCC_AHB1_OTGHS 29
+#define STM32F4_RCC_AHB1_OTGHSULPI 30
#define STM32F4_AHB1_RESET(bit) (STM32F4_RCC_AHB1_##bit + (0x10 * 8))
#define STM32F4_AHB1_CLOCK(bit) (STM32F4_RCC_AHB1_##bit)
@@ -40,6 +46,7 @@
/* AHB3 */
#define STM32F4_RCC_AHB3_FMC 0
+#define STM32F4_RCC_AHB3_QSPI 1
#define STM32F4_AHB3_RESET(bit) (STM32F4_RCC_AHB3_##bit + (0x18 * 8))
#define STM32F4_AHB3_CLOCK(bit) (STM32F4_RCC_AHB3_##bit + 0x40)
@@ -79,7 +86,9 @@
#define STM32F4_RCC_APB2_TIM8 1
#define STM32F4_RCC_APB2_USART1 4
#define STM32F4_RCC_APB2_USART6 5
-#define STM32F4_RCC_APB2_ADC 8
+#define STM32F4_RCC_APB2_ADC1 8
+#define STM32F4_RCC_APB2_ADC2 9
+#define STM32F4_RCC_APB2_ADC3 10
#define STM32F4_RCC_APB2_SDIO 11
#define STM32F4_RCC_APB2_SPI1 12
#define STM32F4_RCC_APB2_SPI4 13
@@ -91,6 +100,7 @@
#define STM32F4_RCC_APB2_SPI6 21
#define STM32F4_RCC_APB2_SAI1 22
#define STM32F4_RCC_APB2_LTDC 26
+#define STM32F4_RCC_APB2_DSI 27
#define STM32F4_APB2_RESET(bit) (STM32F4_RCC_APB2_##bit + (0x24 * 8))
#define STM32F4_APB2_CLOCK(bit) (STM32F4_RCC_APB2_##bit + 0xA0)
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: stm32: Use clock DT binding definition on stm32f429 family
From: gabriel.fernandez @ 2017-01-09 9:07 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, daniel.thompson, andrea.merello, radoslaw.pietrzyk
Cc: devicetree, amelie.delaunay, olivier.bideau, linux-kernel,
linux-clk, linux-arm-kernel, gabriel.fernandez, ludovic.barre
In-Reply-To: <1483952833-14704-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch uses clock DT binding definition instead numerical values
for stm32f429 board.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
arch/arm/boot/dts/stm32429i-eval.dts | 2 +-
arch/arm/boot/dts/stm32f429.dtsi | 66 +++++++++++++++++++-----------------
2 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 76f7206..4e31881 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -107,7 +107,7 @@
usbotg_hs_phy: usbphy {
#phy-cells = <0>;
compatible = "usb-nop-xceiv";
- clocks = <&rcc 0 30>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(OTGHSULPI)>;
clock-names = "main_clk";
};
};
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 041e3fc..1bacdfb 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -49,6 +49,7 @@
#include "armv7-m.dtsi"
#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
#include <dt-bindings/clock/stm32fx-clock.h>
+#include <dt-bindings/mfd/stm32f4-rcc.h>
/ {
clocks {
@@ -82,7 +83,7 @@
compatible = "st,stm32-timer";
reg = <0x40000000 0x400>;
interrupts = <28>;
- clocks = <&rcc 0 128>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM2)>;
status = "disabled";
};
@@ -90,7 +91,7 @@
compatible = "st,stm32-timer";
reg = <0x40000400 0x400>;
interrupts = <29>;
- clocks = <&rcc 0 129>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM3)>;
status = "disabled";
};
@@ -98,7 +99,7 @@
compatible = "st,stm32-timer";
reg = <0x40000800 0x400>;
interrupts = <30>;
- clocks = <&rcc 0 130>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM4)>;
status = "disabled";
};
@@ -106,14 +107,14 @@
compatible = "st,stm32-timer";
reg = <0x40000c00 0x400>;
interrupts = <50>;
- clocks = <&rcc 0 131>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM5)>;
};
timer6: timer@40001000 {
compatible = "st,stm32-timer";
reg = <0x40001000 0x400>;
interrupts = <54>;
- clocks = <&rcc 0 132>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM6)>;
status = "disabled";
};
@@ -121,7 +122,7 @@
compatible = "st,stm32-timer";
reg = <0x40001400 0x400>;
interrupts = <55>;
- clocks = <&rcc 0 133>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM7)>;
status = "disabled";
};
@@ -129,7 +130,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004400 0x400>;
interrupts = <38>;
- clocks = <&rcc 0 145>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART2)>;
status = "disabled";
};
@@ -137,7 +138,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004800 0x400>;
interrupts = <39>;
- clocks = <&rcc 0 146>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART3)>;
status = "disabled";
dmas = <&dma1 1 4 0x400 0x0>,
<&dma1 3 4 0x400 0x0>;
@@ -148,7 +149,7 @@
compatible = "st,stm32-uart";
reg = <0x40004c00 0x400>;
interrupts = <52>;
- clocks = <&rcc 0 147>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART4)>;
status = "disabled";
};
@@ -156,7 +157,7 @@
compatible = "st,stm32-uart";
reg = <0x40005000 0x400>;
interrupts = <53>;
- clocks = <&rcc 0 148>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART5)>;
status = "disabled";
};
@@ -164,7 +165,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40007800 0x400>;
interrupts = <82>;
- clocks = <&rcc 0 158>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART7)>;
status = "disabled";
};
@@ -172,7 +173,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40007c00 0x400>;
interrupts = <83>;
- clocks = <&rcc 0 159>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART8)>;
status = "disabled";
};
@@ -180,7 +181,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40011000 0x400>;
interrupts = <37>;
- clocks = <&rcc 0 164>;
+ clocks = <&rcc 0 STM32F4_APB2_CLOCK(USART1)>;
status = "disabled";
dmas = <&dma2 2 4 0x400 0x0>,
<&dma2 7 4 0x400 0x0>;
@@ -191,7 +192,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40011400 0x400>;
interrupts = <71>;
- clocks = <&rcc 0 165>;
+ clocks = <&rcc 0 STM32F4_APB2_CLOCK(USART6)>;
status = "disabled";
};
@@ -226,7 +227,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x0 0x400>;
- clocks = <&rcc 0 0>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOA)>;
st,bank-name = "GPIOA";
};
@@ -234,7 +235,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x400 0x400>;
- clocks = <&rcc 0 1>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOB)>;
st,bank-name = "GPIOB";
};
@@ -242,7 +243,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x800 0x400>;
- clocks = <&rcc 0 2>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOC)>;
st,bank-name = "GPIOC";
};
@@ -250,7 +251,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0xc00 0x400>;
- clocks = <&rcc 0 3>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOD)>;
st,bank-name = "GPIOD";
};
@@ -258,7 +259,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x1000 0x400>;
- clocks = <&rcc 0 4>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOE)>;
st,bank-name = "GPIOE";
};
@@ -266,7 +267,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x1400 0x400>;
- clocks = <&rcc 0 5>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOF)>;
st,bank-name = "GPIOF";
};
@@ -274,7 +275,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x1800 0x400>;
- clocks = <&rcc 0 6>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOG)>;
st,bank-name = "GPIOG";
};
@@ -282,7 +283,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x1c00 0x400>;
- clocks = <&rcc 0 7>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOH)>;
st,bank-name = "GPIOH";
};
@@ -290,7 +291,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x2000 0x400>;
- clocks = <&rcc 0 8>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOI)>;
st,bank-name = "GPIOI";
};
@@ -298,7 +299,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x2400 0x400>;
- clocks = <&rcc 0 9>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOJ)>;
st,bank-name = "GPIOJ";
};
@@ -306,7 +307,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x2800 0x400>;
- clocks = <&rcc 0 10>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOK)>;
st,bank-name = "GPIOK";
};
@@ -384,7 +385,7 @@
<16>,
<17>,
<47>;
- clocks = <&rcc 0 21>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(DMA1)>;
#dma-cells = <4>;
};
@@ -399,7 +400,7 @@
<68>,
<69>,
<70>;
- clocks = <&rcc 0 22>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(DMA2)>;
#dma-cells = <4>;
st,mem2mem;
};
@@ -411,7 +412,9 @@
interrupts = <61>;
interrupt-names = "macirq";
clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx";
- clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(ETHMAC)>,
+ <&rcc 0 STM32F4_AHB1_CLOCK(ETHMACTX)>,
+ <&rcc 0 STM32F4_AHB1_CLOCK(ETHMACRX)>;
st,syscon = <&syscfg 0x4>;
snps,pbl = <8>;
snps,mixed-burst;
@@ -422,7 +425,7 @@
compatible = "snps,dwc2";
reg = <0x40040000 0x40000>;
interrupts = <77>;
- clocks = <&rcc 0 29>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(OTGHS)>;
clock-names = "otg";
status = "disabled";
};
@@ -431,12 +434,13 @@
compatible = "st,stm32-rng";
reg = <0x50060800 0x400>;
interrupts = <80>;
- clocks = <&rcc 0 38>;
+ clocks = <&rcc 0 STM32F4_AHB2_CLOCK(RNG)>;
+
};
};
};
&systick {
- clocks = <&rcc 1 0>;
+ clocks = <&rcc 1 SYSTICK>;
status = "okay";
};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
From: Inki Dae @ 2017-01-09 9:19 UTC (permalink / raw)
To: Andrzej Hajda, Andi Shyti
Cc: linux-samsung-soc, devicetree, Donghwa Lee, linux-kernel, krzk,
jh80.chung, cw00.choi, kgene, dri-devel, Hyungwon Hwang,
Hoegeun Kwon
In-Reply-To: <5df95abe-0d5d-0c48-2840-5996260201de@samsung.com>
2017년 01월 09일 16:37에 Andrzej Hajda 이(가) 쓴 글:
> On 06.01.2017 09:36, Inki Dae wrote:
>>
>> 2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
>>> Hi Inki,
>>>
>>> Thanks for the reply, but...
>>>
>>>>>> +static const struct drm_display_mode default_mode = {
>>>>>> + .clock = 222372,
>>>>>> + .hdisplay = 1440,
>>>>>> + .hsync_start = 1440 + 1,
>>>>>> + .hsync_end = 1440 + 1 + 1,
>>>>>> + .htotal = 1440 + 1 + 1 + 1,
>>>>>> + .vdisplay = 2560,
>>>>>> + .vsync_start = 2560 + 1,
>>>>>> + .vsync_end = 2560 + 1 + 1,
>>>>>> + .vtotal = 2560 + 1 + 1 + 15,
>>>>>> + .vrefresh = 60,
>>>>>> + .flags = 0,
>>>>>> +};
>>>>> how is this working with tm2e? Are these values valid for both
>>>>> the boards?
>>>> We don't need to consider tm2e board with two reasones,
>>>> 1. there is no tm2e board support in mainline
>>>> 2. the panel on tm2 would be a little bit different from one on tm2e
>>> ... this display in the Tizen Kernel is supported by both:
>>> tm2 [1] and tm2e [2]. The only differences are:
>> Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :(
>>
>>> TM2:
>>> clock-frequency = <14874444>;
>>> hactive = <1440>;
>>>
>>> TM2E:
>>> clock-frequency = <16523724>;
>>> hactive = <1600>;
>>>
>>> I don't know much about the differences you mention in point 2,
>>> but it's a pity to drop support only because we don't want to put
>>> in the dts the 'hactive', and 'clock-frequency' properties.
>> Anyway, tm2e board is already in mainline so Panel driver may need to identify what kinds of panel is probed to decide porch values. I think there are relevant registers in MCU of the Panel device to check version or similar thing.
>
> I think we can safely use different compatible string for tm2e - it uses
> different display IC controller - s6e3hf2, driver will provide timings
> based on it.
Using compatable string wouldn't be a good idea because Panel is a device not specific to board.
> As far as I examined available specs/docs there is no reliable register
> which can be used to safely distinguish it on runtime, but the docs I
> have are far from completeness.
The data sheet I am seeing says a RDDIDS register describes manufacturer and module version information. With this we could identify the Panel device.
Of course, we may need to check the register has really different values according to board.
Below is the version information Hoegeun checked,
TM2
[ 4.908666] panel_s6e3ha2 13900000.dsi.0: Manufacture date: 2014-10-31 06:41
[ 5.035768] panel_s6e3ha2 13900000.dsi.0: Id: 50 20 09
TM2e
[ 4.929265] panel_s6e3ha2 13900000.dsi.0: Manufacture date: 2014-09-03 06:30
[ 5.056287] panel_s6e3ha2 13900000.dsi.0: Id: 40 40 14
Thanks.
>
> Regards
> Andrzej
>
>>
>> Thanks.
>>
>>> Andi
>>>
>>> [1] https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
>>> [2] https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> .
>>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
From: Andrzej Hajda @ 2017-01-09 9:53 UTC (permalink / raw)
To: Inki Dae, Andi Shyti
Cc: linux-samsung-soc, devicetree, Donghwa Lee, linux-kernel, krzk,
jh80.chung, cw00.choi, kgene, dri-devel, Hyungwon Hwang,
Hoegeun Kwon
In-Reply-To: <587355B8.2050701@samsung.com>
On 09.01.2017 10:19, Inki Dae wrote:
>
> 2017년 01월 09일 16:37에 Andrzej Hajda 이(가) 쓴 글:
>> On 06.01.2017 09:36, Inki Dae wrote:
>>> 2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
>>>> Hi Inki,
>>>>
>>>> Thanks for the reply, but...
>>>>
>>>>>>> +static const struct drm_display_mode default_mode = {
>>>>>>> + .clock = 222372,
>>>>>>> + .hdisplay = 1440,
>>>>>>> + .hsync_start = 1440 + 1,
>>>>>>> + .hsync_end = 1440 + 1 + 1,
>>>>>>> + .htotal = 1440 + 1 + 1 + 1,
>>>>>>> + .vdisplay = 2560,
>>>>>>> + .vsync_start = 2560 + 1,
>>>>>>> + .vsync_end = 2560 + 1 + 1,
>>>>>>> + .vtotal = 2560 + 1 + 1 + 15,
>>>>>>> + .vrefresh = 60,
>>>>>>> + .flags = 0,
>>>>>>> +};
>>>>>> how is this working with tm2e? Are these values valid for both
>>>>>> the boards?
>>>>> We don't need to consider tm2e board with two reasones,
>>>>> 1. there is no tm2e board support in mainline
>>>>> 2. the panel on tm2 would be a little bit different from one on tm2e
>>>> ... this display in the Tizen Kernel is supported by both:
>>>> tm2 [1] and tm2e [2]. The only differences are:
>>> Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :(
>>>
>>>> TM2:
>>>> clock-frequency = <14874444>;
>>>> hactive = <1440>;
>>>>
>>>> TM2E:
>>>> clock-frequency = <16523724>;
>>>> hactive = <1600>;
>>>>
>>>> I don't know much about the differences you mention in point 2,
>>>> but it's a pity to drop support only because we don't want to put
>>>> in the dts the 'hactive', and 'clock-frequency' properties.
>>> Anyway, tm2e board is already in mainline so Panel driver may need to identify what kinds of panel is probed to decide porch values. I think there are relevant registers in MCU of the Panel device to check version or similar thing.
>> I think we can safely use different compatible string for tm2e - it uses
>> different display IC controller - s6e3hf2, driver will provide timings
>> based on it.
> Using compatable string wouldn't be a good idea because Panel is a device not specific to board.
But both panels are different devices:
TM2 has: AMS567DJ01 panel on S6E3HA2 interface (called LDI/IC)
TM2E has AMB559DE01 panel on S6E3HF2 interface (called LDI/IC)
Why assigning different compatibles to different devices is not a good idea?
>
>> As far as I examined available specs/docs there is no reliable register
>> which can be used to safely distinguish it on runtime, but the docs I
>> have are far from completeness.
> The data sheet I am seeing says a RDDIDS register describes manufacturer and module version information. With this we could identify the Panel device.
> Of course, we may need to check the register has really different values according to board.
>
> Below is the version information Hoegeun checked,
>
> TM2
> [ 4.908666] panel_s6e3ha2 13900000.dsi.0: Manufacture date: 2014-10-31 06:41
> [ 5.035768] panel_s6e3ha2 13900000.dsi.0: Id: 50 20 09
>
> TM2e
> [ 4.929265] panel_s6e3ha2 13900000.dsi.0: Manufacture date: 2014-09-03 06:30
> [ 5.056287] panel_s6e3ha2 13900000.dsi.0: Id: 40 40 14
There is description of ID1, ID2, ID3 registers in specs of both panels,
I see no reliable bits to distinguish panels.
And relying on read values of random devices does not seems to me proper
solution.
Regards
Andrzej
>
>
> Thanks.
>
>> Regards
>> Andrzej
>>
>>> Thanks.
>>>
>>>> Andi
>>>>
>>>> [1] https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
>>>> [2] https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>> .
>>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 3/3] ARM: dts: sun6i: Add SPDIF to the Mele I7
From: Maxime Ripard @ 2017-01-09 10:03 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: Code Kipper, linux-arm-kernel, devicetree, linux-sunxi
In-Reply-To: <CAGb2v66atehFNDu-G94_WoFXzCPfZev4xsGD8ghr7+_gx-PZJg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
On Sun, Jan 08, 2017 at 03:16:22AM +0800, Chen-Yu Tsai wrote:
> On Tue, Dec 20, 2016 at 6:40 PM, <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > From: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >
> > Enable the S/PDIF transmitter that is present on the Mele I7.
> >
> > Signed-off-by: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>
> This patch should be ready to be merged. The associated clk
> and dtsi changes are already in Maxime's tree.
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: usb:xhci: support disable usb2 LPM Remote Wakeup
From: Thang Q. Nguyen @ 2017-01-09 10:15 UTC (permalink / raw)
To: Mathias Nyman
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Mathias Nyman, Greg Kroah-Hartman, devicetree, linux-kernel,
linux-usb, Phong Vo, Loc Ho, patches
In-Reply-To: <584E9F59.8080303@linux.intel.com>
On Mon, Dec 12, 2016 at 8:00 PM, Mathias Nyman
<mathias.nyman@linux.intel.com> wrote:
> On 12.12.2016 06:00, Thang Q. Nguyen wrote:
>>
>> On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring <robh@kernel.org> wrote:
>>>
>>> On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote:
>>>>
>>>> From: Thang Nguyen <tqnguyen@apm.com>
>>>>
>>>> As per USB 2.0 link power management addendum ECN, table 1-2, page 4,
>>>> device or host initiated via resume signaling; device-initiated resumes
>>>> can be optionally enabled/disabled by software. This patch adds support
>>>> to control enabling the USB2 RWE feature via DT/ACPI attribute.
>>>>
>>>> Signed-off-by: Vu Nguyen <vnguyen@apm.com>
>>>> Signed-off-by: Thang Nguyen <tqnguyen@apm.com>
>>>> ---
>>>> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>>>> drivers/usb/host/xhci-plat.c | 3 +++
>>>> drivers/usb/host/xhci.c | 5 ++++-
>>>> drivers/usb/host/xhci.h | 1 +
>>>> 4 files changed, 9 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> index 966885c..9b4cd14 100644
>>>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>>> @@ -25,6 +25,7 @@ Required properties:
>>>>
>>>> Optional properties:
>>>> - clocks: reference to a clock
>>>> + - usb2-rwe-disable: disable USB2 LPM Remote Wakeup capable
>>>
>>>
>>> Remote wakeup has been around since USB 1.0 days. Does this need to be
>>> USB2 or XHCI specific?
>>
>> This is XHCI specific. Per XHCI specification 1.1, remote wakeup is
>> optional for XHCI 1.0 and required for XHCI 1.1. This patch provides
>> ability for software to disable RWE for USB2 in XHCI1.0 controller.
>
>
> I think I understand what's going on.
>
> USB:
> The good old USB2 suspend is called L2. Device enters it after 3ms if
> there is no link activity.
> If a device can remote wakeup (RWE) it's stated in the descriptor. RWE can
> be turned on
> of off using standard SET/CLEAR Fature requests
>
> The LPM L1 USB2 state again is entered with a LPM extended transaction to
> avoid the
> 3ms wait before powersaving. L1 state is exit can be done with a simialr RWE
> as L2 resume.
> The RWE from L1 can turned on/off using a bit in the LPM extended
> transaction.
>
> XHCI:
>
> Specs say that if the device supports RWE we should enable it for LPM L1
> exit as well.
> This is done by setting the RWE (LPM L1) bit in PORTPMSC register. This bit
> only affect LPM L1 remote
> wake. see 4.23.5.1.1.1
>
> The issue might be that xhci driver never check if the device actually
> supports RWE, we always
> set the PORTPMSC RWE (for LPM L1) bit.
Yes, we should check if device support Remote Wakeup to enable or
disable RWE as noted in cases 1 (page 265) and 2 (page 266) from
4.23.5.1.1.1.
>
> How about checking something like udev->do_remote_wakeup and setting and
> setting the bit
> based on that.
>
> The function that you are changing, xhci_set_usb2_hardware_lpm() should
> only be used if
> host has Hardware LPM Cabaility bit (HLC) set for that USB2 port in the
> USB 2.0 xHCI Supported Protocol Capability.
> Host that don't supprt LPM won't have that set. See xhci 7.2.2.1.3.2
When hosts support Hardware LPM (HLC), any problem if we add a DT/ACPI
attribute to support disable it (HLE=0)?
> -Mathias
>
>
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH v2 02/12] driver: clocksource: add gpt timer for imx6sll
From: Daniel Lezcano @ 2017-01-09 10:30 UTC (permalink / raw)
To: Bai Ping
Cc: mark.rutland, devicetree, p.zabel, mturquette, sboyd, linux-clk,
linux-gpio, robh+dt, kernel, jacky.baip, fabio.estevam, tglx,
shawnguo, linus.walleij, linux-arm-kernel
In-Reply-To: <1482832070-22668-3-git-send-email-ping.bai@nxp.com>
On Tue, Dec 27, 2016 at 05:47:40PM +0800, Bai Ping wrote:
> Add gpt timer support for i.MX6SLL.
>
> Signed-off-by: Bai Ping <ping.bai@nxp.com>
> ---
> drivers/clocksource/timer-imx-gpt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clocksource/timer-imx-gpt.c b/drivers/clocksource/timer-imx-gpt.c
> index f595460..f71822d 100644
> --- a/drivers/clocksource/timer-imx-gpt.c
> +++ b/drivers/clocksource/timer-imx-gpt.c
> @@ -556,4 +556,5 @@ static int __init imx6dl_timer_init_dt(struct device_node *np)
> CLOCKSOURCE_OF_DECLARE(imx6q_timer, "fsl,imx6q-gpt", imx31_timer_init_dt);
> CLOCKSOURCE_OF_DECLARE(imx6dl_timer, "fsl,imx6dl-gpt", imx6dl_timer_init_dt);
> CLOCKSOURCE_OF_DECLARE(imx6sl_timer, "fsl,imx6sl-gpt", imx6dl_timer_init_dt);
> +CLOCKSOURCE_OF_DECLARE(imx6sll_timer, "fsl,imx6sll-gpt", imx6dl_timer_init_dt);
> CLOCKSOURCE_OF_DECLARE(imx6sx_timer, "fsl,imx6sx-gpt", imx6dl_timer_init_dt);
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC 3/4] dt-bindings: correct marvell orion MDIO binding document
From: Mark Rutland @ 2017-01-09 10:31 UTC (permalink / raw)
To: Russell King
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, devicetree, netdev,
Rob Herring, Gregory Clement, Marcin Wojtas, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <E1cPpAk-0005uJ-TM@rmk-PC.armlinux.org.uk>
On Sat, Jan 07, 2017 at 11:28:30AM +0000, Russell King wrote:
> Correct the Marvell Orion MDIO binding document to properly reflect the
> cases where an interrupt is present. Augment the examples to show this.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
This looks fine to me.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> .../devicetree/bindings/net/marvell-orion-mdio.txt | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
> index 9417e54c26c0..ca733ff68ab9 100644
> --- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
> +++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
> @@ -7,7 +7,10 @@ interface.
>
> Required properties:
> - compatible: "marvell,orion-mdio"
> -- reg: address and length of the SMI register
> +- reg: address and length of the MDIO registers. When an interrupt is
> + not present, the length is the size of the SMI register (4 bytes)
> + otherwise it must be 0x84 bytes to cover the interrupt control
> + registers.
>
> Optional properties:
> - interrupts: interrupt line number for the SMI error/done interrupt
> @@ -17,7 +20,7 @@ The child nodes of the MDIO driver are the individual PHY devices
> connected to this MDIO bus. They must have a "reg" property given the
> PHY address on the MDIO bus.
>
> -Example at the SoC level:
> +Example at the SoC level without an interrupt property:
>
> mdio {
> #address-cells = <1>;
> @@ -26,6 +29,16 @@ mdio {
> reg = <0xd0072004 0x4>;
> };
>
> +Example with an interrupt property:
> +
> +mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "marvell,orion-mdio";
> + reg = <0xd0072004 0x84>;
> + interrupts = <30>;
> +};
> +
> And at the board level:
>
> mdio {
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 1/3] arm64: dts: exynos5433: add DECON_TV node
From: Andrzej Hajda @ 2017-01-09 10:40 UTC (permalink / raw)
To: linux-samsung-soc, Krzysztof Kozlowski
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Inki Dae, Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree, Andi Shyti, Chanwoo Choi
In-Reply-To: <CGME20170109104054eucas1p258d1df5ecff1d8b8c9aa882d8c86d5df@eucas1p2.samsung.com>
DECON_TV is 2nd display controller on Exynos5433, used in HDMI path
or 2nd DSI path.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Hi Krzysztof,
These patches are based on latest patches separating tm2 and tm2e and
touchscreen patches. I hope this is good base.
Thanks all for quick response/review.
Regards
Andrzej
v2:
- replaced magic numbers with macros,
- removed power domains,
- removed 0x prefixes from node names
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 43 ++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 68f764e..5552f77 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -814,6 +814,29 @@
};
};
+ decon_tv: decon@13880000 {
+ compatible = "samsung,exynos5433-decon-tv";
+ reg = <0x13880000 0x20b8>;
+ clocks = <&cmu_disp CLK_PCLK_DECON_TV>,
+ <&cmu_disp CLK_ACLK_DECON_TV>,
+ <&cmu_disp CLK_ACLK_SMMU_TV0X>,
+ <&cmu_disp CLK_ACLK_XIU_TV0X>,
+ <&cmu_disp CLK_PCLK_SMMU_TV0X>,
+ <&cmu_disp CLK_SCLK_DECON_TV_VCLK>,
+ <&cmu_disp CLK_SCLK_DECON_TV_ECLK>;
+ clock-names = "pclk", "aclk_decon", "aclk_smmu_decon0x",
+ "aclk_xiu_decon0x", "pclk_smmu_decon0x",
+ "sclk_decon_vclk", "sclk_decon_eclk";
+ samsung,disp-sysreg = <&syscon_disp>;
+ interrupt-names = "fifo", "vsync", "lcd_sys";
+ interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ iommus = <&sysmmu_tv0x>, <&sysmmu_tv1x>;
+ iommu-names = "m0", "m1";
+ };
+
syscon_disp: syscon@13b80000 {
compatible = "syscon";
reg = <0x13b80000 0x1010>;
@@ -912,6 +935,26 @@
#iommu-cells = <0>;
};
+ sysmmu_tv0x: sysmmu@13a20000 {
+ compatible = "samsung,exynos-sysmmu";
+ reg = <0x13a20000 0x1000>;
+ interrupts = <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "pclk", "aclk";
+ clocks = <&cmu_disp CLK_PCLK_SMMU_TV0X>,
+ <&cmu_disp CLK_ACLK_SMMU_TV0X>;
+ #iommu-cells = <0>;
+ };
+
+ sysmmu_tv1x: sysmmu@13a30000 {
+ compatible = "samsung,exynos-sysmmu";
+ reg = <0x13a30000 0x1000>;
+ interrupts = <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "pclk", "aclk";
+ clocks = <&cmu_disp CLK_PCLK_SMMU_TV1X>,
+ <&cmu_disp CLK_ACLK_SMMU_TV1X>;
+ #iommu-cells = <0>;
+ };
+
sysmmu_gscl0: sysmmu@0x13C80000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13C80000 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: exynos5433: add HDMI node
From: Andrzej Hajda @ 2017-01-09 10:40 UTC (permalink / raw)
To: linux-samsung-soc, Krzysztof Kozlowski
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Inki Dae, Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree, Andi Shyti, Chanwoo Choi
In-Reply-To: <1483958437-6572-1-git-send-email-a.hajda@samsung.com>
HDMI converts RGB/I80 signal from DECON_TV to HDMI/TMDS video stream.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
v2:
- replaced magic numbers with macros,
- removed power domains
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 5552f77..f82d26e 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -837,6 +837,35 @@
iommu-names = "m0", "m1";
};
+ hdmi: hdmi@13970000 {
+ compatible = "samsung,exynos5433-hdmi";
+ reg = <0x13970000 0x70000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu_disp CLK_PCLK_HDMI>,
+ <&cmu_disp CLK_PCLK_HDMIPHY>,
+ <&cmu_disp CLK_PHYCLK_HDMIPHY_TMDS_CLKO>,
+ <&cmu_disp CLK_PHYCLK_HDMI_PIXEL>,
+ <&cmu_disp CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY>,
+ <&cmu_disp CLK_MOUT_PHYCLK_HDMIPHY_TMDS_CLKO_USER>,
+ <&cmu_disp CLK_PHYCLK_HDMIPHY_PIXEL_CLKO_PHY>,
+ <&cmu_disp CLK_MOUT_PHYCLK_HDMIPHY_PIXEL_CLKO_USER>,
+ <&xxti>, <&cmu_disp CLK_SCLK_HDMI_SPDIF>;
+ clock-names = "hdmi_pclk", "hdmi_i_pclk",
+ "i_tmds_clk", "i_pixel_clk",
+ "tmds_clko", "tmds_clko_user",
+ "pixel_clko", "pixel_clko_user",
+ "oscclk", "i_spdif_clk";
+ phy = <&hdmiphy>;
+ ddc = <&hsi2c_11>;
+ samsung,syscon-phandle = <&pmu_system_controller>;
+ samsung,sysreg-phandle = <&syscon_disp>;
+ status = "disabled";
+ };
+
+ hdmiphy: hdmiphy@13af0000 {
+ reg = <0x13af0000 0x80>;
+ };
+
syscon_disp: syscon@13b80000 {
compatible = "syscon";
reg = <0x13b80000 0x1010>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: exynos5433-tm2: enable HDMI/TV path
From: Andrzej Hajda @ 2017-01-09 10:40 UTC (permalink / raw)
To: linux-samsung-soc, Krzysztof Kozlowski
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Inki Dae, Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree, Andi Shyti, Chanwoo Choi
In-Reply-To: <1483958437-6572-1-git-send-email-a.hajda@samsung.com>
TV path consist of following interconnected components:
- DECON_TV - display controller,
- HDMI - video signal converter RGB / HDMI,
- MHL - video signal converter HDMI / MHL,
- DDC - i2c slave device for EDID reading (on hsi2c_11 bus).
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
v2:
- replaced magic numbers with macros,
- removed assigned-clock properties from sii8620 -
PMU clock is already confgured in PMU node
---
.../boot/dts/exynos/exynos5433-tm2-common.dtsi | 69 ++++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 669bb1f..ca90e6a 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -281,6 +281,22 @@
};
};
+&decon_tv {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ tv_to_hdmi: endpoint {
+ remote-endpoint = <&hdmi_to_tv>;
+ };
+ };
+ };
+};
+
&dsi {
status = "okay";
vddcore-supply = <&ldo6_reg>;
@@ -304,6 +320,33 @@
};
};
+&hdmi {
+ hpd-gpios = <&gpa3 0 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ vdd-supply = <&ldo6_reg>;
+ vdd_osc-supply = <&ldo7_reg>;
+ vdd_pll-supply = <&ldo6_reg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ hdmi_to_tv: endpoint {
+ remote-endpoint = <&tv_to_hdmi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ hdmi_to_mhl: endpoint {
+ remote-endpoint = <&mhl_to_hdmi>;
+ };
+ };
+ };
+};
+
&hsi2c_0 {
status = "okay";
clock-frequency = <2500000>;
@@ -692,6 +735,28 @@
};
};
+&hsi2c_7 {
+ status = "okay";
+
+ sii8620@39 {
+ reg = <0x39>;
+ compatible = "sil,sii8620";
+ cvcc10-supply = <&ldo36_reg>;
+ iovcc18-supply = <&ldo34_reg>;
+ interrupt-parent = <&gpf0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+ reset-gpios = <&gpv7 0 GPIO_ACTIVE_LOW>;
+ clocks = <&pmu_system_controller 0>;
+ clock-names = "xtal";
+
+ port {
+ mhl_to_hdmi: endpoint {
+ remote-endpoint = <&hdmi_to_mhl>;
+ };
+ };
+ };
+};
+
&hsi2c_8 {
status = "okay";
@@ -735,6 +800,10 @@
};
};
+&hsi2c_11 {
+ status = "okay";
+};
+
&i2s0 {
status = "okay";
};
--
2.7.4
^ 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