* [PATCH V3] ARM: dts: armada388-helios4
From: Dennis Gilmore @ 2018-06-05 18:48 UTC (permalink / raw)
To: linux-kernel, jason, andrew, gregory.clement,
sebastian.hesselbarth, robh+dt, mark.rutland, linux-arm-kernel,
devicetree
Cc: Dennis Gilmore
The helios4 is a Armada388 based nas board designed by SolidRun and
based on their SOM. It is sold by kobol.io the dts file came from
https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
I added a SPDX license line to match the clearfog it says it was based
on and a compatible line for "kobol,helios4"
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
changes since first submission
change solidrun to kobol in compatible line based on feedback
changes since v2
remove commented out nodes based on feedback
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 313 +++++++++++++++++++++++
2 files changed, 314 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..490bfd586198 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
+ armada-388-helios4.dtb \
armada-388-rd.dtb
dtb-$(CONFIG_MACH_ARMADA_39X) += \
armada-398-db.dtb
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts b/arch/arm/boot/dts/armada-388-helios4.dts
new file mode 100644
index 000000000000..59048740ae06
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Helios4
+ * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2017
+ *
+ */
+
+/dts-v1/;
+#include "armada-388.dtsi"
+#include "armada-38x-solidrun-microsom.dtsi"
+
+/ {
+ model = "Helios4";
+ compatible = "kobol,helios4", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x80000000>; /* 2 GB */
+ };
+
+ aliases {
+ /* So that mvebu u-boot can update the MAC addresses */
+ ethernet1 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_12v: regulator-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "power_brick_12V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_hdd: regulator-5v-hdd {
+ compatible = "regulator-fixed";
+ regulator-name = "5V_HDD";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_usb: regulator-5v-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB-PWR";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&expander0 6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <®_12v>;
+ };
+
+ system-leds {
+ compatible = "gpio-leds";
+ status-led {
+ label = "helios4:green:status";
+ gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ fault-led {
+ label = "helios4:red:fault";
+ gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+ };
+
+ io-leds {
+ compatible = "gpio-leds";
+ sata1-led {
+ label = "helios4:green:ata1";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata1";
+ default-state = "off";
+ };
+ sata2-led {
+ label = "helios4:green:ata2";
+ gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata2";
+ default-state = "off";
+ };
+ sata3-led {
+ label = "helios4:green:ata3";
+ gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata3";
+ default-state = "off";
+ };
+ sata4-led {
+ label = "helios4:green:ata4";
+ gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata4";
+ default-state = "off";
+ };
+ usb-led {
+ label = "helios4:green:usb";
+ gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "usb-host";
+ default-state = "off";
+ };
+ };
+
+ fan1: j10-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 9 40000>; /* Target freq:25 kHz */
+ };
+
+ fan2: j17-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 23 40000>; /* Target freq:25 kHz */
+ };
+
+ usb2_phy: usb2-phy {
+ compatible = "usb-nop-xceiv";
+ vbus-regulator = <®_5p0v_usb>;
+ };
+
+ usb3_phy: usb3-phy {
+ compatible = "usb-nop-xceiv";
+ };
+
+ soc {
+ internal-regs {
+ i2c@11000 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ /*
+ * PCA9655 GPIO expander, up to 1MHz clock.
+ * 0-Board Revision bit 0 #
+ * 1-Board Revision bit 1 #
+ * 5-USB3 overcurrent
+ * 6-USB3 power
+ */
+ expander0: gpio-expander@20 {
+ /*
+ * This is how it should be:
+ * compatible = "onnn,pca9655",
+ * "nxp,pca9555";
+ * but you can't do this because of
+ * the way I2C works.
+ */
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pca0_pins>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ board_rev_bit_0 {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-0";
+ };
+ board_rev_bit_1 {
+ gpio-hog;
+ gpios = <1 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-1";
+ };
+ usb3_ilimit {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "usb-overcurrent-status";
+ };
+ };
+
+ temp_sensor: temp@4c {
+ compatible = "ti,lm75";
+ reg = <0x4c>;
+ vcc-supply = <®_3p3v>;
+ };
+ };
+
+ i2c@11100 {
+ /*
+ * External I2C Bus for user peripheral
+ */
+ clock-frequency = <400000>;
+ pinctrl-0 = <&helios_i2c1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sata@a8000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata0: sata-port@0 {
+ reg = <0>;
+ };
+
+ sata1: sata-port@1 {
+ reg = <1>;
+ };
+ };
+
+ sata@e0000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata2: sata-port@0 {
+ reg = <0>;
+ };
+
+ sata3: sata-port@1 {
+ reg = <1>;
+ };
+ };
+
+ spi@10680 {
+ pinctrl-0 = <&spi1_pins
+ µsom_spi1_cs_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sdhci@d8000 {
+ bus-width = <4>;
+ cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ pinctrl-0 = <&helios_sdhci_pins
+ &helios_sdhci_cd_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ vmmc = <®_3p3v>;
+ wp-inverted;
+ };
+
+ usb@58000 {
+ usb-phy = <&usb2_phy>;
+ status = "okay";
+ };
+
+ usb3@f0000 {
+ status = "okay";
+ };
+
+ usb3@f8000 {
+ status = "okay";
+ };
+
+ pinctrl@18000 {
+ pca0_pins: pca0-pins {
+ marvell,pins = "mpp23";
+ marvell,function = "gpio";
+ };
+ microsom_phy0_int_pins: microsom-phy0-int-pins {
+ marvell,pins = "mpp18";
+ marvell,function = "gpio";
+ };
+ helios_i2c1_pins: i2c1-pins {
+ marvell,pins = "mpp26", "mpp27";
+ marvell,function = "i2c1";
+ };
+ helios_sdhci_cd_pins: helios-sdhci-cd-pins {
+ marvell,pins = "mpp20";
+ marvell,function = "gpio";
+ };
+ helios_sdhci_pins: helios-sdhci-pins {
+ marvell,pins = "mpp21", "mpp28",
+ "mpp37", "mpp38",
+ "mpp39", "mpp40";
+ marvell,function = "sd0";
+ };
+ helios_led_pins: helios-led-pins {
+ marvell,pins = "mpp24", "mpp25",
+ "mpp49", "mpp50",
+ "mpp52", "mpp53",
+ "mpp54";
+ marvell,function = "gpio";
+ };
+ helios_fan_pins: helios-fan-pins {
+ marvell,pins = "mpp41", "mpp43",
+ "mpp48", "mpp55";
+ marvell,function = "gpio";
+ };
+ microsom_spi1_cs_pins: spi1-cs-pins {
+ marvell,pins = "mpp59";
+ marvell,function = "spi1";
+ };
+ };
+ };
+ };
+};
--
2.17.1
^ permalink raw reply related
* Re: [alsa-devel] [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
From: Takashi Iwai @ 2018-06-05 18:29 UTC (permalink / raw)
To: Arnaud Pouliquen
Cc: Mark Brown, Olivier MOYSAN, alsa-devel@alsa-project.org,
mark.rutland@arm.com, rmk@arm.linux.org.uk, lgirdwood@gmail.com,
mcoquelin.stm32@gmail.com, robh@kernel.org,
linux-arm-kernel@lists.infradead.org, Alexandre TORGUE,
Benjamin GAIGNARD, kernel@stlinux.com, jsarha@ti.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <2ae6c5b6-872a-9aaa-6ca4-e29adb7c8bc0@st.com>
On Tue, 05 Jun 2018 17:50:57 +0200,
Arnaud Pouliquen wrote:
>
> Hi Takashi,
>
> On 04/17/2018 01:17 PM, Mark Brown wrote:
> > On Tue, Apr 17, 2018 at 08:29:17AM +0000, Olivier MOYSAN wrote:
> >
> >> I guess the blocking patch in this patchset is the patch "add IEC958
> >> channel status control helper". This patch has been reviewed several
> >> times, but did not get a ack so far.
> >> If you think these helpers will not be merged, I will reintegrate the
> >> corresponding code in stm driver.
> >> Please let me know, if I need to prepare a v2 without helpers, or if we
> >> can go further in the review of iec helpers patch ?
> >
> > I don't mind either way but you're right here, I'm waiting for Takashi
> > to review the first patch. I'd probably be OK with it just integrated
> > into the driver if we have to go that way though.
>
> Gentlemen reminder for this patch set. We would appreciate to have your
> feedback on iec helper.
> From our point of view it could be useful to have a generic management
> of the iec controls based on helpers instead of redefining them in DAIs.
> Having the same behavior for these controls could be useful to ensure
> coherence of the control management used by application (for instance
> Gstreamer uses it to determine iec raw mode capability for iec61937 streams)
Oh sorry for the late reply, I've totally overlooked the thread.
And, another sorry: the patchset doesn't look convincing enough to
me.
First off, the provided API definition appears somewhat
unconventional, the mixture of the ops, the static data and the
dynamic data.
Moreover, this is only for your driver, ATM. If it were an API that
does clean up the already existing usages, I'd happily apply it. There
are lots of drivers creating and controlling the IEC958 ctls even
now.
Also, the patchset requires more fine-tuning, in anyways. The changes
in create_iec958_consumre() are basically irrelevant, should be split
off as an individual fix. Also, the new function doesn't create the
"XXX Mask" controls. And the byte comparison should be replaced with
memcmp(), etc, etc.
So, please proceed rather with the open codes for now. If you can
provide a patch that cleans up the *multiple* driver codes, again,
I'll happily take it. But it can be done anytime later, too.
thanks,
Takashi
^ permalink raw reply
* Re: Re: [PATCH v2] arm: sun4i: Add support for Pengpod 1000 tablet
From: Bob Ham @ 2018-06-05 18:18 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ
Cc: Chen-Yu Tsai, Hans de Goede, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180605145038.qptdlcphdbnw6jyg@flea>
[-- Attachment #1.1: Type: text/plain, Size: 2314 bytes --]
On 05/06/18 15:50, Maxime Ripard wrote:
> On Mon, Jun 04, 2018 at 06:33:02PM +0100, Bob Ham wrote:
>> On 04/06/18 09:13, Maxime Ripard wrote:
>>> On Sat, Jun 02, 2018 at 05:03:13PM +0100, Bob Ham wrote:
>>
>>>> + * 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.
>>
>>>> + * The above copyright notice and this permission notice shall be
>>>> + * included in all copies or substantial portions of the Software.
>>
>>> And this is redundant with the SPDX header.
>>
>> The X11 license notice states explicitly that the notice has to be
>> included in the file. Wouldn't removing it be a violation of the license?
>
> The SPDX header is explicitly here to remove the license text and
> create a tag that is in a indirect reference to the license text in
> LICENSES. It's not going away.
Well, the top bit that I quoted above says that the licenses refer to
only that one file in particular and not the project as a whole. Then
the X11 license states that the notice can't be removed from 'this
software and associated documentation files (the "Software")' which
would seem to refer to the single file. Therefore, removing the notice
from the single file and replacing it with an SPDX header would seem to
violate the license.
It's a fine point but it makes me nervous. I originally based my .dts
on sun4i-a10-inet1.dts. I've CC'd the original copyright holder, Hans
de Goede. Hans, are you willing to give permission for the license
notice to be replaced with just an SPDX header indicating the dual
licensing?
While we're at it, there are a number of other files with the same
license text. Hans, are you prepared to give permission for your other
license notices to be replaced with SPDX headers?
Thanks,
Bob
--
Bob Ham <rah-2mWpNWY8JZLk1uMJSBkQmQ@public.gmane.org>
for (;;) { ++pancakes; }
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 2913 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Frank Rowand @ 2018-06-05 17:34 UTC (permalink / raw)
To: Michel Pollet, linux-renesas-soc, Simon Horman
Cc: Michel Pollet, Mark Rutland, phil.edworthy, Florian Fainelli,
Rajendra Nayak, devicetree, linux-kernel, Stefan Wahren,
Magnus Damm, Russell King, Douglas Anderson, Chen-Yu Tsai,
Rob Herring, Carlo Caione, Andreas Färber, Frank Rowand,
linux-arm-kernel
In-Reply-To: <1528198148-23308-3-git-send-email-michel.pollet@bp.renesas.com>
On 06/05/18 04:28, Michel Pollet wrote:
> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time, it
> requires a special enable method to get it started.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> ---
> arch/arm/mach-shmobile/Makefile | 1 +
> arch/arm/mach-shmobile/smp-r9a06g032.c | 79 ++++++++++++++++++++++++++++++++++
> 2 files changed, 80 insertions(+)
> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>
> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
> index 1939f52..d7fc98f 100644
> --- a/arch/arm/mach-shmobile/Makefile
> +++ b/arch/arm/mach-shmobile/Makefile
> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.o headsmp-scu.o platsmp-scu.o
> smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o platsmp-scu.o
> smp-$(CONFIG_ARCH_R8A7790) += smp-r8a7790.o
> smp-$(CONFIG_ARCH_R8A7791) += smp-r8a7791.o
> +smp-$(CONFIG_ARCH_R9A06G032) += smp-r9a06g032.o
> smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o platsmp-scu.o
>
> # PM objects
> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c b/arch/arm/mach-shmobile/smp-r9a06g032.c
> new file mode 100644
> index 0000000..cd40e6e
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * R9A06G032 Second CA7 enabler.
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
> + * Derived from action,s500-smp
> + */
> +
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/smp.h>
> +
> +/*
> + * The second CPU is parked in ROM at boot time. It requires waking it after
> + * writing an address into the BOOTADDR register of sysctrl.
> + *
> + * So the default value of the "cpu-release-addr" corresponds to BOOTADDR...
> + *
> + * *However* the BOOTADDR register is not available when the kernel
> + * starts in NONSEC mode.
> + *
> + * So for NONSEC mode, the bootloader re-parks the second CPU into a pen
> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a SRAM address,
> + * which is not restricted.
The binding document for cpu-release-addr does not have a definition for 32 bit
arm. The existing definition is only 64 bit arm. Please add the definition
for 32 bit arm to patch 1.
-Frank
> + */
> +
> +static void __iomem *cpu_bootaddr;
> +
> +static DEFINE_SPINLOCK(cpu_lock);
> +
> +static int r9a06g032_smp_boot_secondary(unsigned int cpu, struct task_struct *idle)
> +{
> + if (!cpu_bootaddr)
> + return -ENODEV;
> +
> + spin_lock(&cpu_lock);
> +
> + writel(__pa_symbol(secondary_startup), cpu_bootaddr);
> + arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> +
> + spin_unlock(&cpu_lock);
> +
> + return 0;
> +}
> +
> +static void __init r9a06g032_smp_prepare_cpus(unsigned int max_cpus)
> +{
> + struct device_node *dn;
> + int ret;
> + u32 bootaddr;
> +
> + dn = of_get_cpu_node(1, NULL);
> + if (!dn) {
> + pr_err("CPU#1: missing device tree node\n");
> + return;
> + }
> + /*
> + * Determine the address from which the CPU is polling.
> + * The bootloader *does* change this property
> + */
> + ret = of_property_read_u32(dn, "cpu-release-addr", &bootaddr);
> + of_node_put(dn);
> + if (ret) {
> + pr_err("CPU#1: invalid cpu-release-addr property\n");
> + return;
> + }
> + pr_info("CPU#1: cpu-release-addr %08x\n", bootaddr);
> +
> + cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr));
> +}
> +
> +static const struct smp_operations r9a06g032_smp_ops __initconst = {
> + .smp_prepare_cpus = r9a06g032_smp_prepare_cpus,
> + .smp_boot_secondary = r9a06g032_smp_boot_secondary,
> +};
> +CPU_METHOD_OF_DECLARE(r9a06g032_smp, "renesas,r9a06g032-smp", &r9a06g032_smp_ops);
>
^ permalink raw reply
* Re: [v5 2/6] dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs
From: Li Yang @ 2018-06-05 17:24 UTC (permalink / raw)
To: Vinod
Cc: Wen He, dmaengine@vger.kernel.org, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Jiafei Pan, Jiaheng Fan
In-Reply-To: <20180605163043.GX16230@vkoul-mobl>
On Tue, Jun 5, 2018 at 11:30 AM, Vinod <vkoul@kernel.org> wrote:
> On 04-06-18, 09:53, Wen He wrote:
>
>>
>> > > +// SPDX-License-Identifier: GPL-2.0
>> > > +// Copyright 2018 NXP
>> >
>> > I know the SPDX tag is recommended to be the 1st line, but copyright normally
>> > goes below the file description not above.
>
> I do not think that is specified anywhere.. can you point it?
No. It is not documented. But the majority of the source files in
Linux are using this header format like below, so I assume it is
something like a convention.
/*
* {filename --} file description
*
* Copyright ...
*
* License ...
*/
The Documentation/process/license-rules.rst only mentioned about the
requirement for SPDX tags. So I think we should keep the format for
other part of the header.
Regards,
Leo
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77990: ebisu: Enable watchdog timer
From: Geert Uytterhoeven @ 2018-06-05 17:20 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-renesas-soc, devicetree, Takeshi Kihara, Geert Uytterhoeven,
linux-arm-kernel
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Add a device node for the Watchdog Timer (WDT) controller on the
R8A77990 SoC, and enable the watchdog on the Ebisu board.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Squashed 2 commits]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 5 +++++
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 10 ++++++++++
2 files changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 7a09d0524f9b0663..28945a8b980080f2 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -60,6 +60,11 @@
};
};
+&rwdt {
+ timeout-sec = <60>;
+ status = "okay";
+};
+
&scif2 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 6d597a1c7636784f..735881d4e57ac1ad 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -69,6 +69,16 @@
#size-cells = <2>;
ranges;
+ rwdt: watchdog@e6020000 {
+ compatible = "renesas,r8a77990-wdt",
+ "renesas,rcar-gen3-wdt";
+ reg = <0 0xe6020000 0 0x0c>;
+ clocks = <&cpg CPG_MOD 402>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 402>;
+ status = "disabled";
+ };
+
gpio0: gpio@e6050000 {
compatible = "renesas,gpio-r8a77990",
"renesas,rcar-gen3-gpio";
--
2.7.4
^ permalink raw reply related
* [PATCH] dt-bindings: watchdog: renesas-wdt: Add support for the R8A77990 wdt
From: Geert Uytterhoeven @ 2018-06-05 17:18 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Mark Rutland
Cc: linux-watchdog, devicetree, linux-renesas-soc, Masaharu Hayakawa,
Geert Uytterhoeven
From: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
Document support for the Watchdog Timer (WDT) Controller in the Renesas
R-Car E3 (R8A77990) SoC.
No driver update is needed.
Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
index f24d802b8056f6c6..5d47a262474cfe0e 100644
--- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
@@ -16,6 +16,7 @@ Required properties:
- "renesas,r8a7796-wdt" (R-Car M3-W)
- "renesas,r8a77965-wdt" (R-Car M3-N)
- "renesas,r8a77970-wdt" (R-Car V3M)
+ - "renesas,r8a77990-wdt" (R-Car E3)
- "renesas,r8a77995-wdt" (R-Car D3)
- "renesas,r7s72100-wdt" (RZ/A1)
The generic compatible string must be:
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
From: Vinod Koul @ 2018-06-05 16:40 UTC (permalink / raw)
To: Sricharan R
Cc: bjorn.andersson, ohad, robh+dt, mark.rutland, andy.gross,
david.brown, linux-remoteproc, devicetree, linux-kernel,
linux-arm-msm, linux-soc, sibis
In-Reply-To: <3a4c102b-7228-153a-c588-b1bf00291fa8@codeaurora.org>
On 05-06-18, 18:26, Sricharan R wrote:
> Hi Vinod,
>
> On 6/5/2018 11:49 AM, Vinod wrote:
> > On 05-06-18, 11:12, Sricharan R wrote:
> >
> >> +config QCOM_Q6V5_WCSS
> >> + tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader"
> >> + depends on OF && ARCH_QCOM
> >> + depends on QCOM_SMEM
> >> + depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)
> >> + depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
> >
> > Is there a reason why it depends on RPMSG_QCOM_GLINK_SMEM=n? What would
> > happen if distro wants both this and RPMSG_QCOM_GLINK_SMEM
> >
> RPMSG_QCOM_GLINK_SMEM=n should be for the COMPILE_TEST. Probably that
why would that be a limitation? I am more worried about
RPMSG_QCOM_GLINK_SMEM=n being the condition here. In new drivers we
should not typically have dependency on some symbol being not there
> means that it should be corrected here and for ADSP, Q6V5_PIL as well.
> Bjorn, is that correct ?, should it be, below ?
>
> depends on (RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)) || (RPMSG_QCOM_GLINK_SMEM || (COMPILE_TEST && RPMSG_QCOM_GLINK_SMEM=n))
that doesnt really sound good :(
--
~Vinod
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: Add Mediatek X20 Development Board support
From: Manivannan Sadhasivam @ 2018-06-05 16:34 UTC (permalink / raw)
To: matthias.bgg, robh+dt
Cc: linux-arm-kernel, linux-mediatek, devicetree, linux-kernel,
taiten.peng, daniel.thompson, amit.kucheria, manivannanece23,
Manivannan Sadhasivam
In-Reply-To: <20180605163442.4812-1-manivannan.sadhasivam@linaro.org>
Add initial device tree support for Mediatek X20 Development Board
based on MT6797 Deca core SoC. This board is one of the 96Boards
Consumer Edition platform.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index ac17f60f998c..5b7fd6ad96e4 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -3,5 +3,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
new file mode 100644
index 000000000000..2c09ca95d9e2
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for MediaTek X20 Development Board
+ *
+ * Copyright (C) 2018, Linaro Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include "mt6797.dtsi"
+
+/ {
+ model = "Mediatek X20 Development Board";
+ compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
+
+ aliases {
+ serial0 = &uart1;
+ };
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x1e605000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&uart1 {
+ status = "okay";
+};
--
2.17.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: arm: mediatek: Document Mediatek X20 Development Board
From: Manivannan Sadhasivam @ 2018-06-05 16:34 UTC (permalink / raw)
To: matthias.bgg, robh+dt
Cc: linux-arm-kernel, linux-mediatek, devicetree, linux-kernel,
taiten.peng, daniel.thompson, amit.kucheria, manivannanece23,
Manivannan Sadhasivam
In-Reply-To: <20180605163442.4812-1-manivannan.sadhasivam@linaro.org>
Document Mediatek X20 Development Board which is a 96Boards Consumer
Edition platform based on MT6797 SoC.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
Documentation/devicetree/bindings/arm/mediatek.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt
index 7d21ab37c19c..356df1ee11b9 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -47,6 +47,9 @@ Supported boards:
- Evaluation board for MT6797(Helio X20):
Required root node properties:
- compatible = "mediatek,mt6797-evb", "mediatek,mt6797";
+- Mediatek X20 Development Board:
+ Required root node properties:
+ - compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
- Reference board variant 1 for MT7622:
Required root node properties:
- compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622";
--
2.17.0
^ permalink raw reply related
* [PATCH v2 0/2] Add Mediatek X20 Development Board support
From: Manivannan Sadhasivam @ 2018-06-05 16:34 UTC (permalink / raw)
To: matthias.bgg, robh+dt
Cc: linux-arm-kernel, linux-mediatek, devicetree, linux-kernel,
taiten.peng, daniel.thompson, amit.kucheria, manivannanece23,
Manivannan Sadhasivam
Add devicetree support for Mediatek X20 Development Board by Archermind.
This board is based on the Deca-Core MT6797 SoC from Mediatek and is
one of the 96Boards Consumer Edition platform.
With this devicetree change, board can boot into initramfs.
More information about this board can be found in 96Boards product page:
https://www.96boards.org/product/mediatek-x20/
Thanks,
Mani
Changes in v2:
* Added documentation for board compatible
* Dropped vendor documetation patch since it got applied
Manivannan Sadhasivam (2):
dt-bindings: arm: mediatek: Document Mediatek X20 Development Board
arm64: dts: Add Mediatek X20 Development Board support
.../devicetree/bindings/arm/mediatek.txt | 3 ++
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
3 files changed, 37 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
--
2.17.0
^ permalink raw reply
* Re: [v5 2/6] dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs
From: Vinod @ 2018-06-05 16:30 UTC (permalink / raw)
To: Wen He
Cc: Leo Li, dmaengine@vger.kernel.org, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Jiafei Pan, Jiaheng Fan
In-Reply-To: <AM6PR0402MB3382F4C81800D91761DA619FE2670@AM6PR0402MB3382.eurprd04.prod.outlook.com>
On 04-06-18, 09:53, Wen He wrote:
>
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +// Copyright 2018 NXP
> >
> > I know the SPDX tag is recommended to be the 1st line, but copyright normally
> > goes below the file description not above.
I do not think that is specified anywhere.. can you point it?
>
> All right, but Vinod recommend this kind of writing.
> May be we need to discuss with Vinod.
--
~Vinod
^ permalink raw reply
* Re: [v5 2/6] dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs
From: Vinod @ 2018-06-05 16:28 UTC (permalink / raw)
To: Wen He
Cc: dmaengine@vger.kernel.org, robh+dt@kernel.org,
devicetree@vger.kernel.org, Leo Li, Jiafei Pan, Jiaheng Fan
In-Reply-To: <AM6PR0402MB3382A63FF2884BAD8AF6080BE2630@AM6PR0402MB3382.eurprd04.prod.outlook.com>
On 31-05-18, 01:58, Wen He wrote:
> > > > > > > +static void fsl_qdma_issue_pending(struct dma_chan *chan) {
> > > > > > > + struct fsl_qdma_chan *fsl_chan = to_fsl_qdma_chan(chan);
> > > > > > > + struct fsl_qdma_queue *fsl_queue = fsl_chan->queue;
> > > > > > > + unsigned long flags;
> > > > > > > +
> > > > > > > + spin_lock_irqsave(&fsl_queue->queue_lock, flags);
> > > > > > > + spin_lock(&fsl_chan->vchan.lock);
> > > > > > > + if (vchan_issue_pending(&fsl_chan->vchan))
> > > > > > > + fsl_qdma_enqueue_desc(fsl_chan);
> > > > > > > + spin_unlock(&fsl_chan->vchan.lock);
> > > > > > > + spin_unlock_irqrestore(&fsl_queue->queue_lock, flags);
> > > > > >
> > > > > > why do we need two locks, and since you are doing vchan why
> > > > > > should you add your own lock on top
> > > > > >
> > > > >
> > > > > Yes, we need two locks.
> > > > > As you know, the QDMA support multiple virtualized blocks for
> > > > > multi-core
> > > > support.
> > > > > so we need to make sure that muliti-core access issues.
> > > >
> > > > but why cant you use vchan lock for all?
> > > >
> > >
> > > We can't only use vchan lock for all. otherwise enqueue action will be
> > interrupted.
> >
> > I think it is possible to use only vchan lock
>
> I tried that if I use only vchan lock then qdma will be can't work.
> Do you have a other good idea?
can you explain the scenario...
--
~Vinod
^ permalink raw reply
* Re: [PATCH] ASoC: ssm2602: Fix ADC powerup sequencing
From: Mark Brown @ 2018-06-05 16:06 UTC (permalink / raw)
To: Philipp Zabel
Cc: Mark Rutland, Rob Herring, Linux-ALSA, Lars-Peter Clausen,
devicetree, Sascha Hauer, Marco Felsch, Liam Girdwood, kernel
In-Reply-To: <1528192731.4074.7.camel@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 2329 bytes --]
On Tue, Jun 05, 2018 at 11:58:51AM +0200, Philipp Zabel wrote:
> On Fri, 2018-05-25 at 18:24 +0100, Mark Brown wrote:
> > If this is varying so drastically per board/system that it's relevant
> > then we're already into problematic territory. For most devices we just
> > have a number for the part, not something that varies so wildly that
> > each system needs to configure it.
> I'm not arguing this should be configured per individual device, just
> per board DT.
Even per board is a very surprising amount of variability TBH.
> It's just that my experience of one datapoint consists of a board where
> I had to increase the delay to about three times the delay calculated
> from the nominal capacitance according to the datasheet before audible
> artifacts disappeared reliably on multiple devices.
> Putting the extended delay into the device tree with a comment
> explaining its empirical nature seemed more straightforward than putting
> a bogus capacitance value, that differs from the schematics, and that I
> have never measured.
The thing that's surprising me here is that there's even a board to
board variance that's so bad that it needs to be configured like this -
usually these things are just hard coded into the driver so they work
for everyone rather than needing per-board tuning. It seems entirely
possible that the formula quoted in the datasheet is just nonsense in
general and that the driver would be better off using your number for
all systems for example. If we do have to hard code something in the DT
it seems better to hard code something that is at least coming from a
spec rather than a measured number that needs to come from an average
over a batch of boards since at least we can revise how we handle the
number without needing to do something that shows up in the ABI.
> Also, by using the capacitance we are guaranteed to end up with a codec
> specific property name (adi,vmid-decoupling-capacitance ?) as opposed to
> the possibility of defining a common delay property that could be used
> for different codecs.
That's actually something I want to avoid since the delays tend to need
to come in the middle of write sequences which makes a general property
a lot more complicated, and obviously some devices have multiple delays
too.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/2] arm: dts: sunxi: Add missing cooling device properties for CPUs
From: Chen-Yu Tsai @ 2018-06-05 16:02 UTC (permalink / raw)
To: Maxime Ripard
Cc: Viresh Kumar, arm-soc, Rob Herring, Mark Rutland, Vincent Guittot,
ionela.voinescu, Daniel Lezcano, chris.redpath, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20180605071139.osu2pgpg3ychdxln@flea>
On Tue, Jun 5, 2018 at 3:11 PM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Tue, Jun 05, 2018 at 10:17:49AM +0530, Viresh Kumar wrote:
>> The cooling device properties, like "#cooling-cells" and
>> "dynamic-power-coefficient", should either be present for all the CPUs
>> of a cluster or none. If these are present only for a subset of CPUs of
>> a cluster then things will start falling apart as soon as the CPUs are
>> brought online in a different order. For example, this will happen
>> because the operating system looks for such properties in the CPU node
>> it is trying to bring up, so that it can register a cooling device.
>>
>> Add such missing properties.
>>
>> Fix other missing properties (clocks, OPP, clock latency) as well to
>> make it all work.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Applied both, thanks!
Please fix the "ARM" prefix when applying. :)
ChenYu
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: stm32: sai: add iec958 controls support
From: Arnaud Pouliquen @ 2018-06-05 15:52 UTC (permalink / raw)
To: Olivier MOYSAN, lgirdwood@gmail.com, broonie@kernel.org,
perex@perex.cz, tiwai@suse.com, mcoquelin.stm32@gmail.com,
Alexandre TORGUE, alsa-devel@alsa-project.org, robh@kernel.org,
mark.rutland@arm.com, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kernel@stlinux.com,
linux-kernel@vger.kernel.org
Cc: jsarha@ti.com, Benjamin GAIGNARD, rmk@arm.linux.org.uk
In-Reply-To: <1520958428-10930-3-git-send-email-olivier.moysan@st.com>
Hi Olivier,
On 03/13/2018 05:27 PM, Olivier MOYSAN wrote:
> Add support of iec958 controls for STM32 SAI.
>
> Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
> ---
> sound/core/pcm_iec958.c | 1 +
> sound/soc/stm/Kconfig | 1 +
> sound/soc/stm/stm32_sai_sub.c | 101
> +++++++++++++++++++++++++++++++++++++-----
> 3 files changed, 91 insertions(+), 12 deletions(-)
>
> diff --git a/sound/core/pcm_iec958.c b/sound/core/pcm_iec958.c
> index aba1f522e98a..c34735ac3c48 100644
> --- a/sound/core/pcm_iec958.c
> +++ b/sound/core/pcm_iec958.c
> @@ -19,6 +19,7 @@ static int snd_pcm_iec958_info(struct snd_kcontrol
> *kcontrol,
> {
> uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
> uinfo->count = 1;
> +
> return 0;
> }
Seems that this should be part of your patch 1/3
Regards,
Arnaud
>
> diff --git a/sound/soc/stm/Kconfig b/sound/soc/stm/Kconfig
> index 48f9ddd94016..9b2681397dba 100644
> --- a/sound/soc/stm/Kconfig
> +++ b/sound/soc/stm/Kconfig
> @@ -6,6 +6,7 @@ config SND_SOC_STM32_SAI
> depends on SND_SOC
> select SND_SOC_GENERIC_DMAENGINE_PCM
> select REGMAP_MMIO
> + select SND_PCM_IEC958
> help
> Say Y if you want to enable SAI for STM32
>
> diff --git a/sound/soc/stm/stm32_sai_sub.c b/sound/soc/stm/stm32_sai_sub.c
> index cfeb219e1d78..c2e487e133aa 100644
> --- a/sound/soc/stm/stm32_sai_sub.c
> +++ b/sound/soc/stm/stm32_sai_sub.c
> @@ -26,6 +26,7 @@
> #include <sound/asoundef.h>
> #include <sound/core.h>
> #include <sound/dmaengine_pcm.h>
> +#include <sound/pcm_iec958.h>
> #include <sound/pcm_params.h>
>
> #include "stm32_sai.h"
> @@ -96,7 +97,7 @@
> * @slot_mask: rx or tx active slots mask. set at init or at runtime
> * @data_size: PCM data width. corresponds to PCM substream width.
> * @spdif_frm_cnt: S/PDIF playback frame counter
> - * @spdif_status_bits: S/PDIF status bits
> + * @snd_aes_iec958: iec958 data
> */
> struct stm32_sai_sub_data {
> struct platform_device *pdev;
> @@ -125,7 +126,7 @@ struct stm32_sai_sub_data {
> int slot_mask;
> int data_size;
> unsigned int spdif_frm_cnt;
> - unsigned char spdif_status_bits[SAI_IEC60958_STATUS_BYTES];
> + struct snd_aes_iec958 iec958;
> };
>
> enum stm32_sai_fifo_th {
> @@ -184,10 +185,6 @@ static bool stm32_sai_sub_writeable_reg(struct
> device *dev, unsigned int reg)
> }
> }
>
> -static const unsigned char
> default_status_bits[SAI_IEC60958_STATUS_BYTES] = {
> - 0, 0, 0, IEC958_AES3_CON_FS_48000,
> -};
> -
> static const struct regmap_config stm32_sai_sub_regmap_config_f4 = {
> .reg_bits = 32,
> .reg_stride = 4,
> @@ -619,6 +616,59 @@ static void stm32_sai_set_frame(struct snd_soc_dai
> *cpu_dai)
> }
> }
>
> +static void stm32_sai_set_channel_status(struct stm32_sai_sub_data *sai,
> + struct snd_pcm_runtime *runtime)
> +{
> + if (!runtime)
> + return;
> +
> + /* Force the sample rate according to runtime rate */
> + switch (runtime->rate) {
> + case 22050:
> + sai->iec958.status[3] = IEC958_AES3_CON_FS_22050;
> + break;
> + case 44100:
> + sai->iec958.status[3] = IEC958_AES3_CON_FS_44100;
> + break;
> + case 88200:
> + sai->iec958.status[3] = IEC958_AES3_CON_FS_88200;
> + break;
> + case 176400:
> + sai->iec958.status[3] = IEC958_AES3_CON_FS_176400;
> + break;
> + case 24000:
> + sai->iec958.status[3] = IEC958_AES3_CON_FS_24000;
> + break;
> + case 48000:
> + sai->iec958.status[3] = IEC958_AES3_CON_FS_48000;
> + break;
> + case 96000:
> + sai->iec958.status[3] = IEC958_AES3_CON_FS_96000;
> + break;
> + case 192000:
> + sai->iec958.status[3] = IEC958_AES3_CON_FS_192000;
> + break;
> + case 32000:
> + sai->iec958.status[3] = IEC958_AES3_CON_FS_32000;
> + break;
> + default:
> + sai->iec958.status[3] = IEC958_AES3_CON_FS_NOTID;
> + break;
> + }
> +}
> +
> +static int stm32_sai_iec958_set(struct snd_pcm_iec958_params *iec_param)
> +{
> + struct stm32_sai_sub_data *sai = iec_param->private_data;
> +
> + if (!sai->substream)
> + return 0;
> +
> + stm32_sai_set_channel_status(sai, sai->substream->runtime);
> +
> + return 0;
> +}
> +
> static int stm32_sai_configure_clock(struct snd_soc_dai *cpu_dai,
> struct snd_pcm_hw_params *params)
> {
> @@ -709,7 +759,11 @@ static int stm32_sai_hw_params(struct
> snd_pcm_substream *substream,
>
> sai->data_size = params_width(params);
>
> - if (!STM_SAI_PROTOCOL_IS_SPDIF(sai)) {
> + if (STM_SAI_PROTOCOL_IS_SPDIF(sai)) {
> + /* Rate not already set in runtime structure */
> + substream->runtime->rate = params_rate(params);
> + stm32_sai_set_channel_status(sai, substream->runtime);
> + } else {
> ret = stm32_sai_set_slots(cpu_dai);
> if (ret < 0)
> return ret;
> @@ -789,6 +843,28 @@ static void stm32_sai_shutdown(struct
> snd_pcm_substream *substream,
> sai->substream = NULL;
> }
>
> +static int stm32_sai_pcm_new(struct snd_soc_pcm_runtime *rtd,
> + struct snd_soc_dai *cpu_dai)
> +{
> + struct stm32_sai_sub_data *sai = dev_get_drvdata(cpu_dai->dev);
> + struct snd_pcm_iec958_params *iec_param;
> +
> + if (STM_SAI_PROTOCOL_IS_SPDIF(sai)) {
> + dev_dbg(&sai->pdev->dev, "%s: register iec controls",
> __func__);
> + iec_param = devm_kzalloc(&sai->pdev->dev,
> sizeof(*iec_param),
> + GFP_KERNEL);
> + iec_param->ctrl_set = stm32_sai_iec958_set;
> + iec_param->private_data = sai;
> + iec_param->cs = sai->iec958.status;
> + iec_param->cs_len = 5;
> + return snd_pcm_add_iec958_ctl(rtd->pcm, 0,
> + SNDRV_PCM_STREAM_PLAYBACK,
> + iec_param);
> + }
> +
> + return 0;
> +}
> +
> static int stm32_sai_dai_probe(struct snd_soc_dai *cpu_dai)
> {
> struct stm32_sai_sub_data *sai = dev_get_drvdata(cpu_dai->dev);
> @@ -809,6 +885,10 @@ static int stm32_sai_dai_probe(struct snd_soc_dai
> *cpu_dai)
> else
> snd_soc_dai_init_dma_data(cpu_dai, NULL, &sai->dma_params);
>
> + /* Next settings are not relevant for spdif mode */
> + if (STM_SAI_PROTOCOL_IS_SPDIF(sai))
> + return 0;
> +
> cr1_mask = SAI_XCR1_RX_TX;
> if (STM_SAI_IS_CAPTURE(sai))
> cr1 |= SAI_XCR1_RX_TX;
> @@ -820,10 +900,6 @@ static int stm32_sai_dai_probe(struct snd_soc_dai
> *cpu_dai)
> sai->synco, sai->synci);
> }
>
> - if (STM_SAI_PROTOCOL_IS_SPDIF(sai))
> - memcpy(sai->spdif_status_bits, default_status_bits,
> - sizeof(default_status_bits));
> -
> cr1_mask |= SAI_XCR1_SYNCEN_MASK;
> cr1 |= SAI_XCR1_SYNCEN_SET(sai->sync);
>
> @@ -861,7 +937,7 @@ static int stm32_sai_pcm_process_spdif(struct
> snd_pcm_substream *substream,
> /* Set channel status bit */
> byte = frm_cnt >> 3;
> mask = 1 << (frm_cnt - (byte << 3));
> - if (sai->spdif_status_bits[byte] & mask)
> + if (sai->iec958.status[byte] & mask)
> *ptr |= 0x04000000;
> ptr++;
>
> @@ -888,6 +964,7 @@ static int stm32_sai_pcm_process_spdif(struct
> snd_pcm_substream *substream,
> static struct snd_soc_dai_driver stm32_sai_playback_dai[] = {
> {
> .probe = stm32_sai_dai_probe,
> + .pcm_new = stm32_sai_pcm_new,
> .id = 1, /* avoid call to fmt_single_name() */
> .playback = {
> .channels_min = 1,
> --
> 1.9.1
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
From: Arnaud Pouliquen @ 2018-06-05 15:50 UTC (permalink / raw)
To: Mark Brown, Olivier MOYSAN
Cc: mark.rutland@arm.com, robh@kernel.org,
alsa-devel@alsa-project.org, Alexandre TORGUE,
devicetree@vger.kernel.org, lgirdwood@gmail.com,
linux-kernel@vger.kernel.org, jsarha@ti.com, tiwai@suse.com,
kernel@stlinux.com, linux-arm-kernel@lists.infradead.org,
mcoquelin.stm32@gmail.com, rmk@arm.linux.org.uk,
Benjamin GAIGNARD
In-Reply-To: <20180417111733.GG8973@sirena.org.uk>
Hi Takashi,
On 04/17/2018 01:17 PM, Mark Brown wrote:
> On Tue, Apr 17, 2018 at 08:29:17AM +0000, Olivier MOYSAN wrote:
>
>> I guess the blocking patch in this patchset is the patch "add IEC958
>> channel status control helper". This patch has been reviewed several
>> times, but did not get a ack so far.
>> If you think these helpers will not be merged, I will reintegrate the
>> corresponding code in stm driver.
>> Please let me know, if I need to prepare a v2 without helpers, or if we
>> can go further in the review of iec helpers patch ?
>
> I don't mind either way but you're right here, I'm waiting for Takashi
> to review the first patch. I'd probably be OK with it just integrated
> into the driver if we have to go that way though.
Gentlemen reminder for this patch set. We would appreciate to have your
feedback on iec helper.
>From our point of view it could be useful to have a generic management
of the iec controls based on helpers instead of redefining them in DAIs.
Having the same behavior for these controls could be useful to ensure
coherence of the control management used by application (for instance
Gstreamer uses it to determine iec raw mode capability for iec61937 streams)
Thanks,
Arnaud
^ permalink raw reply
* Re: [PATCH v5 3/4] clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Rob Herring @ 2018-06-05 15:49 UTC (permalink / raw)
To: Matti Vaittinen
Cc: mturquette, sboyd, mark.rutland, lee.jones, lgirdwood, broonie,
mazziesaccount, linux-clk, devicetree, linux-kernel,
mikko.mutanen, heikki.haikola
In-Reply-To: <da121dede6d79460c5653a5bc360d413cb988c74.1528117485.git.matti.vaittinen@fi.rohmeurope.com>
On Mon, Jun 04, 2018 at 04:18:53PM +0300, Matti Vaittinen wrote:
> Document devicetree bindings for ROHM BD71837 PMIC clock output.
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> ---
> .../bindings/clock/rohm,bd71837-clock.txt | 38 ++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
> new file mode 100644
> index 000000000000..771acfe34114
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
> @@ -0,0 +1,38 @@
> +ROHM BD71837 Power Management Integrated Circuit clock bindings
This needs to be added to the MFD doc. One node should be covered by at
most 1 document.
Rob
^ permalink raw reply
* Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays
From: Noralf Trønnes @ 2018-06-05 15:49 UTC (permalink / raw)
To: David Lechner, dri-devel, devicetree
Cc: Mark Rutland, limor, linux-kernel, Rob Herring, Nitin Patil
In-Reply-To: <d5297fc5-94f2-edcd-5a11-95d7a9dca78d@lechnology.com>
(cc: drm-misc maintainers)
Den 04.06.2018 03.21, skrev David Lechner:
>
>
> On 6/3/18 5:00 PM, Noralf Trønnes wrote:
>>
>> Den 25.05.2018 21.36, skrev David Lechner:
>>> This series adds a new tinydrm driver for the Ilitek ILI9341
>>> controller and
>>> a 2.4" display panel that uses this controller.
>>
>> David, do you have commit rights now?
>
> No. Opened a bug a while back to request access, but I guess the
> right person didn't see it.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=105166
>
Could someone please look at this?
Noralf.
>>
>> Noralf.
>>
>>> A few things to note here:
>>> * The datasheet for this display[1] doesn't have a vendor mentioned
>>> on it
>>> anywhere, so I have used "adafruit" as the vendor prefix. If
>>> someone has a
>>> better suggestion, please speak up.
>>> * The MAINTAINERS patch for ili9225 is included so we don't end up
>>> with a merge
>>> conflict later on.
>>>
>>> v2 changes:
>>> * change vendor prefix from "noname" to "adafruit"
>>> * new patch for "adafruit" vendor prefix
>>> * minor style changes
>>> * drop regulator from driver (instead of adding to DT bindings)
>>>
>>> [1]:
>>> https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf
>>>
>>>
>>>
>>> David Lechner (4):
>>> MAINTAINERS: fix path to ilitek,ili9225 device tree bindings
>>> dt-bindings: Add vendor prefix for Adafruit
>>> dt-bindings: new binding for Ilitek ILI9341 display panels
>>> drm/tinydrm: new driver for ILI9341 display panels
>>>
>>> .../bindings/display/ilitek,ili9341.txt | 27 ++
>>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>>> MAINTAINERS | 8 +-
>>> drivers/gpu/drm/tinydrm/Kconfig | 10 +
>>> drivers/gpu/drm/tinydrm/Makefile | 1 +
>>> drivers/gpu/drm/tinydrm/ili9341.c | 233
>>> ++++++++++++++++++
>>> 6 files changed, 279 insertions(+), 1 deletion(-)
>>> create mode 100644
>>> Documentation/devicetree/bindings/display/ilitek,ili9341.txt
>>> create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c
>>>
>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v5 2/4] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Rob Herring @ 2018-06-05 15:47 UTC (permalink / raw)
To: Matti Vaittinen
Cc: mturquette, sboyd, mark.rutland, lee.jones, lgirdwood, broonie,
mazziesaccount, linux-clk, devicetree, linux-kernel,
mikko.mutanen, heikki.haikola
In-Reply-To: <6509bbe0238c20c16930c9f23d63656b1d5f4af2.1528117485.git.matti.vaittinen@fi.rohmeurope.com>
On Mon, Jun 04, 2018 at 04:18:30PM +0300, Matti Vaittinen wrote:
> Document devicetree bindings for ROHM BD71837 PMIC MFD.
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> ---
> .../devicetree/bindings/mfd/rohm,bd71837-pmic.txt | 76 ++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
I've replied on the prior version discussion. Please don't send new
versions if the last one is still under discussion.
Rob
^ permalink raw reply
* Re: [PATCH v4 2/6] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Rob Herring @ 2018-06-05 15:46 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Michael Turquette, Stephen Boyd, Mark Rutland,
Lee Jones, Liam Girdwood, Mark Brown, linux-clk, devicetree,
linux-kernel@vger.kernel.org, mikko.mutanen, heikki.haikola
In-Reply-To: <20180604113225.GE5150@localhost.localdomain>
On Mon, Jun 4, 2018 at 6:32 AM, Matti Vaittinen
<mazziesaccount@gmail.com> wrote:
> On Fri, Jun 01, 2018 at 12:32:16PM -0500, Rob Herring wrote:
>> On Fri, Jun 1, 2018 at 1:25 AM, Matti Vaittinen
>> <mazziesaccount@gmail.com> wrote:
>> > On Thu, May 31, 2018 at 09:07:24AM -0500, Rob Herring wrote:
>> >> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen
>> >> <mazziesaccount@gmail.com> wrote:
>> >> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote:
>> >> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote:
>> >> >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote:
>> >> >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD.
>> >> >> > > + - interrupts : The interrupt line the device is connected to.
>> >> >> > > + - interrupt-controller : Marks the device node as an interrupt controller.
>> >> >> >
>> >> >> > What sub blocks have interrupts?
>> >> >>
>> >> >> The PMIC can generate interrupts from events which cause it to reset.
>> >> >> Eg, irq from watchdog line change, power button pushes, reset request
>> >> >> via register interface etc. I don't know any generic handling for these
>> >> >> interrupts. In "normal" use-case this PMIC is powering the processor
>> >> >> where driver is running and I do not see reasonable handling because
>> >> >> power-reset is going to follow the irq.
>> >> >>
>> >> >
>> >> > Oh, but when reading this I understand that the interrupt-controller
>> >> > property should at least be optional.
>> >>
>> >> I don't think it should. The h/w either has an interrupt controller or
>> >> it doesn't.
>> >
>> > I hope this explains why I did this interrupt controller - please tell
>> > me if this is legitimate use-case and what you think of following:
>> >
>> > +Optional properties:
>> > + - interrupt-controller : Marks the device node as an interrupt controller.
>> > + BD71837MWV can report different power state change
>> > + events to other devices. Different events can be seen
>> > + as separate BD71837 domain interrupts.
>>
>> To what other devices?
>
> Would it be better if I wrote "other drivers" instead? I think I've seen
> examples where MFD driver is just providing the interrupts for other
> drivers - like power-button input driver. Currently I have no such "irq
> consumer" drivers written. Still I would like to expose these interrupts
> so that they are ready for using if any platform using PMIC needs them.
No, worse. Interrupt binding describes interrupt connections between a
controller and devices (which could be sub-blocks in a device), not to
drivers.
I'm just curious as to what sub-blocks/devices there are. You don't
have to have a driver (yet) to define the devices.
>
> I think there are other similar drivers in tree. For example TPS6591x
> driver seems to be doing this. (Has MFD driver exposing the interrupts
> but no driver handling those). Maybe explanation like this would help:
>
> "The BD71837 driver only provides the infrastructure for the IRQs. The
> users can write his own driver to convert the IRQ into the event they
> wish. The IRQ can be used with the standard
> request_irq/enable_irq/disable_irq API inside the kernel." (I found this
> text from NXP forums and ruthlessly copied and modified it over here)
That's all OS details that have nothing to do with the binding. The
binding describes the h/w.
> If this is not feasible, then I will remove the irq handling from MFD
> (or leave code there but remove the binding information?) as I don't
> know what the irq handles should do in generic case.
I don't understand what you mean by generic. An IRQ has to be wired to
something. The only generic IRQs are GPIOs.
>> > + - #interrupt-cells : The number of cells to describe an IRQ should be 1.
>> > + The first cell is the IRQ number.
>> > + masks from ../interrupt-controller/interrupts.txt.
>
> Sorry this "masks from ../interrupt-controller/interrupts.txt." was
> accidentally pasted here. I should have deleted it.
>
>> I'm still not clear. Generally in a PMIC, you'd define an interrupt
>> controller when there's a common set of registers to manage sub-block
>> interrupts (typical mask/unmask, ack regs) and the subblocks
>> themselves have control of masking/unmasking interrupts. If there's
>> not a need to have these 2 levels of interrupt handling, then you
>> don't really need to define an interrupt controller.
>
> And to clarify - the PMIC can generate irq via one irq line. This is
> typical ACTIVE_LOW irq with 8 bit "write 1 to clear" status register and
> 8 bit mask register. The role of interrupt-controller code here is just
> to allow these 8 irq reasons to be seen as individual BD71837 domain
> interrupts. I just don't have the driver(s) for handling these
> interrupts.
If what I'm asking for above is still not clear, what are the 8 bits
defined as or what are those 8 lines connected to?
>
>> >> My concern is you added it but nothing uses it which tells
>> >> me your binding is incomplete. I'd rather see complete bindings even
>> >> if you don't have drivers.
>> >
>> > So this makes me wonder if my use-case for interrupt controller is
>> > valid. I thought making this PMIC as interrupt controller is a nice way
>> > of hiding the irq register and i2c access from other potential drivers
>> > using these interrupts. But as I don't know what could be the potential
>> > user for these irqs, I don't know how to complete binding. This is why I
>> > also thought of making this optional, so that the potential for using
>> > the interrupts would be there but it was not required when interrupts
>> > are not needed.
>>
>> The only drivers getting these interrupts would be drivers for this
>> PMIC. Interrupts are handled by the driver owning the h/w that
>> generated the interrupt. I think that is the disconnect here.
>>
>> Take a power button. We don't create a generic power button interrupt
>> and then have some generic power button interrupt handler. We have a
>> handler for specifically for that device and then it generates a power
>> button press event.
>
> I think I understand this. Here we also have a 'power button' interrupt
> from PMIC (as one of the interrupts) here. But what happens when button
> is pressed depends on PMIC configuration. I guess we might want a power
> button driver here - and this power button driver might be correct user
> for the irq. So are you stating that I should write the power button
> driver (or some other "IRQ consumer") before adding the
> interrupt-controller property to bindings for MFD?
No. Bindings come before drivers.
> Or should I just
> somehow state that irq X in BD71837 is a "power button short push"
> event and power button driver should be the consumer for it?
Yes, at least, but who is the consumer is an OS detail that is not
relevant to the binding. Ideally, you would describe the node with the
interrupts property for "irq X".
> Rest of the interrupts are not so obvious. I have no idea how I should
> handle rest of the interrupts. Those are interrupts which cause the PMIC
> to reset and cut the powers from most of the regulators too. I can
> easily think setup where one processor is controlling PMIC which powers
> for the other processor. And getting IRQ if for example watchdog reset
> the other processor would probably be very usefull. But doing any
> 'de-facto' handler for this is hard. Only generally usefull thing would
> be notifying the user-space but I don't think I should invent any new
> kernelspace - userspace interfaces for this. I believe that when such
> are needed those should be implemented by ones knowing the platform.
Don't think about the OS or driver details. Think about sub-blocks of
the hardware and the connections between them (like irqs) and to board
that need to be described in DT.
If you can't describe that, then you just probably shouldn't have
sub-nodes in DT (ever). Though adding later is easier than trying to
remove them.
>
> So please bear with me but do you mean I should
> a) document what conditions generate which IRQ
> or
> b) should I tell what kind of driver is needed for handling the IRQs
> or
> c) should I first write code using IRQs before addinf MFD binding?
A.
> a) I can do.
> b) I think I can't do this for most of the irqs as in normal use-case
> the processor won't catch these as it is going to be powered down.
> c) I might be able to do this for power button IRQ but it might not be
> what user wants in the end.
>
>> >> My concern is you added it but nothing uses it which tells
>> >> me your binding is incomplete. I'd rather see complete bindings even
>> >> if you don't have drivers.
>
> Can you please tell if I misunderstood this?
>
> Br,
> Matti Vaittinen
>
^ permalink raw reply
* Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524
From: Andy Shevchenko @ 2018-06-05 15:37 UTC (permalink / raw)
To: Pavel Machek
Cc: H. Nikolaus Schaller, Kumar Gala, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Linus Walleij, Alexandre Courbot,
devicetree, open list:GPIO SUBSYSTEM, Linux Kernel Mailing List,
Discussions about the Letux Kernel, kernel
In-Reply-To: <20180523140635.GB27215@amd>
On Wed, May 23, 2018 at 5:06 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote:
>> The register constants are so far defined in a way that they fit
>> for the pcal9555a when shifted by the number of banks, i.e. are
>> multiplied by 2 in the accessor function.
>>
>> Now, the pcal6524 has 3 banks which means the relative offset
>> is multiplied by 4 for the standard registers.
>>
>> Simply applying the bit shift to the extended registers gives
>> a wrong result, since the base offset is already included in
>> the offset.
>>
>> Therefore, we have to add code to the 24 bit accessor functions
>> that adjusts the register number for these exended registers.
>>
>> The formula finally used was developed and proposed by
>> Andy Shevchenko <andy.shevchenko@gmail.com>.
>> int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
>> + int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
>> + int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
> Is this reasonable to do on each register access? Compiler will not be
> able to optimize out fls and shifts, right?
On modern CPUs fls() is one assembly command. OTOH, any proposal to do
this better?
What I can see is that bank_shift is invariant to the function, and
maybe cached.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 2/4] dt-bindings: timer: add i.MX EPIT timer binding
From: Rob Herring @ 2018-06-05 15:23 UTC (permalink / raw)
To: Clément Péron
Cc: Colin Didier, linux-arm-kernel, devicetree, linux-kernel,
Daniel Lezcano, Thomas Gleixner, Fabio Estevam,
Vladimir Zapolskiy, Sascha Hauer, NXP Linux Team,
Pengutronix Kernel Team, Clément Peron
In-Reply-To: <20180604100035.19558-3-peron.clem@gmail.com>
On Mon, Jun 04, 2018 at 12:00:33PM +0200, Clément Péron wrote:
> From: Clément Peron <clement.peron@devialet.com>
>
> Add devicetree binding document for NXP's i.MX SoC specific
> EPIT timer driver.
>
> Signed-off-by: Clément Peron <clement.peron@devialet.com>
> ---
> .../devicetree/bindings/timer/fsl,imxepit.txt | 21 +++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,imxepit.txt b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> new file mode 100644
> index 000000000000..de2e6ef68d24
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> @@ -0,0 +1,21 @@
> +Binding for the i.MX Enhanced Periodic Interrupt Timer (EPIT)
> +
> +The Enhanced Periodic Interrupt Timer (EPIT) is a 32-bit set-and-forget timer
> +that is capable of providing precise interrupts at regular intervals with
> +minimal processor intervention.
> +
> +Required properties:
> +- compatible: should be "fsl,<chip>-epit", "fsl,imx31-epit" where <chip> is
> + imx25, imx6qdl, imx6sl, imx6sul or imx6sx.
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- interrupts: Should contain EPIT controller interrupt
> +- clocks : The clock provided by the SoC to drive the timer.
> +
> +Example for i.MX6QDL:
> + epit1: epit@20d0000 {
I think I already mentioned this, but:
timer@...
> + compatible = "fsl,imx6qdl-epit", "fsl,imx31-epit";
> + reg = <0x020d0000 0x4000>;
> + interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_EPIT1>;
> + };
> --
> 2.17.0
>
^ permalink raw reply
* Re: [PATCH v8 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
From: Rob Herring @ 2018-06-05 15:20 UTC (permalink / raw)
To: Sandeep Panda
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, ryadav-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
robdclark-Re5JQEeQqe8AvxtiuMwx3w, nganji-sgV2jX0FEOL9JmXXK+q4OQ,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, abhinavk-sgV2jX0FEOL9JmXXK+q4OQ,
hoegsberg-F7+t8E8rja9g9hUCZPvPmw,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
jsanka-sgV2jX0FEOL9JmXXK+q4OQ, chandanu-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <1528177218-1051-4-git-send-email-spanda-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue, Jun 05, 2018 at 11:10:16AM +0530, Sandeep Panda wrote:
> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
>
> Changes in v1:
> - Rephrase the dt-binding descriptions to be more inline with existing
> bindings (Andrzej Hajda).
> - Add missing dt-binding that are parsed by corresponding driver
> (Andrzej Hajda).
>
> Changes in v2:
> - Remove edp panel specific dt-binding entries. Only keep bridge
> specific entries (Sean Paul).
> - Remove custom-modes dt entry since its usage is removed from driver also (Sean Paul).
> - Remove is-pluggable dt entry since this will not be needed anymore (Sean Paul).
>
> Changes in v3:
> - Remove irq-gpio dt entry and instead populate is an interrupt
> property (Rob Herring).
>
> Changes in v4:
> - Add link to bridge chip datasheet (Stephen Boyd)
> - Add vpll and vcc regulator supply bindings (Stephen Boyd)
> - Add ref clk optional dt binding (Stephen Boyd)
> - Add gpio-controller optional dt binding (Stephen Boyd)
>
> Changes in v5:
> - Use clock property to specify the input refclk (Stephen Boyd).
> - Update gpio cell and pwm cell numbers (Stephen Boyd).
>
> Changes in v6:
> - Add property to mention the lane mapping scheme and polarity inversion
> (Stephen Boyd).
>
> Changes in v7:
> - Detail description of lane mapping scheme dt property (Andrzej
> Hajda/ Rob Herring).
> - Removed HDP gpio binding, since the bridge uses IRQ signal to
> determine HPD, and IRQ property is already documented in binding.
>
> Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
> ---
> .../bindings/display/bridge/ti,sn65dsi86.txt | 109 +++++++++++++++++++++
> 1 file changed, 109 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> new file mode 100644
> index 0000000..33329f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> @@ -0,0 +1,109 @@
> +SN65DSI86 DSI to eDP bridge chip
> +--------------------------------
> +
> +This is the binding for Texas Instruments SN65DSI86 bridge.
> +http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
> +
> +Required properties:
> +- compatible: Must be "ti,sn65dsi86"
> +- reg: i2c address of the chip, 0x2d as per datasheet
> +- enable-gpios: OF device-tree gpio specification for bridge_en pin (active high)
> +
> +- vccio-supply: A 1.8V supply that powers up the digital IOs.
> +- vpll-supply: A 1.8V supply that powers up the displayport PLL.
> +- vcca-supply: A 1.2V supply that powers up the analog circuits.
> +- vcc-supply: A 1.2V supply that powers up the digital core.
> +
> +Optional properties:
> +- interrupts: Specifier for the SN65DSI86 interrupt line.
> +
> +- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing
> +
> +- gpio-controller: Marks the device has a GPIO controller.
> +- #gpio-cells : Should be two. The first cell is the pin number and
> + the second cell is used to specify flags.
> + See ../../gpio/gpio.txt for more information.
> +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of
> + the cell formats.
> +
> +- clock-names: should be "refclk"
> +- clocks: Specification for input reference clock. The reference
> + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
> +
> +- lane-mapping: Specification to describe the logical to physical lane
As I mentioned in v7, we already have a property for this. It's called
'data-lanes' and defined in media/video-interfaces.txt. Use that. If you
need polarity too, then add a property for that. And add it to
video-interfaces.txt.
> + mapping scheme and polarity inversion of eDP lanes on PCB.
> + Each pair present at index n (where n lies between 0 and 3)
> + describes the lane mapping of logical lane to physical lane n
> + and the polarity(it should be either 1 or 0) of the physical lane n.
> +
> + For example:
> + lane-mapping = <2 1>,
> + <1 0>,
> + <3 1>,
> + <0 0>;
> +
> + The above mapping describes that logical lane 2 is mapped to
> + physical lane 0 and polarity of physical lane 0 is inverted,
> + logical lane 1 is mapped to physical lane 1 and polarity of
> + physical lane 1 is normal, logical lane 3 is mapped to physical
> + lane 2 and polarity of physical lane 2 is inverted, logical lane 0
> + is mapped to physical lane 4 and polarity of physical lane 3 is normal.
> +
> + If this property is not mentioned then it is assumed that physical
> + lanes 0 through 3 are mapped to logical lanes 0 through 3 and polarity
> + of all physical lanes is normal.
> +
> +Required nodes:
> +This device has two video ports. Their connections are modelled using the
> +OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for DSI input
> +- Video port 1 for eDP output
> +
> +Example
> +-------
> +
> +edp-bridge@2d {
> + compatible = "ti,sn65dsi86";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x2d>;
> +
> + enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
> +
> + vccio-supply = <&pm8916_l17>;
> + vcca-supply = <&pm8916_l6>;
> + vpll-supply = <&pm8916_l17>;
> + vcc-supply = <&pm8916_l6>;
> +
> + clock-names = "refclk";
> + clocks = <&input_refclk>;
> +
> + lane-mapping = <0 0>, /* Logical lane 0 is routed to physical lane 0 (!inv) */
> + <1 1>, /* Logical lane 1 is routed to physical lane 1 (inv) */
> + <2 0>, /* Logical lane 2 is routed to physical lane 2 (!inv) */
> + <3 1>; /* Logical lane 3 is routed to physical lane 3 (inv) */
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + edp_bridge_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + edp_bridge_out: endpoint {
> + remote-endpoint = <&edp_panel_in>;
> + };
> + };
> + };
> +}
> --
> The Qualcomm Innovation Center, Inc. is a member of the 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply
* Re: [PATCH 0/2] Add Mediatek X20 Development Board support
From: Matthias Brugger @ 2018-06-05 15:15 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh+dt, linux-arm-kernel, linux-mediatek, devicetree,
linux-kernel, taiten.peng, daniel.thompson, amit.kucheria,
manivannanece23, Mars Cheng, Saber Rezvani
In-Reply-To: <20180529072719.GA5529@Mani-XPS-13-9360>
On 29/05/18 09:27, Manivannan Sadhasivam wrote:
> Hi Matthias,
>
> On Tue, May 29, 2018 at 08:38:27AM +0200, Matthias Brugger wrote:
>> Hi Manivannan,
>>
>> it's nice to see that someone at Linaro cares about upstreaming the 96 board.
>> From what I can see, your patches add the very same support to the board as
>> does the mt6797 evaluation board. Do you have plans to upstream more drivers for
>> the board? Do you have a roadmap or something?
>>
>> I'm asking becuase I don't want to have just another dead devicetree in the
>> kernel which does nothing but provides a boot to rootfs. Especially as this can
>> be achieved on the same board with the EVB dts.
>>
>
> I can understand your concern here. I do have plans to add more drivers
> in the future for this board but I can't give you any roadmap for that
> since it mostly falls under the spare time work and I have been doing a
> similar kind of work for the Bubblegum-96 board in parallel.
>
> At most I can guarentee that this board's functionality will be added
> gradually in upcoming days.
>
Sounds good. Fancy to send a v2 with the comments from Rob?
Regards,
Matthias
> Thanks,
> Mani
>
>> Regards,
>> Matthias
>>
>> On 29/05/18 06:52, Manivannan Sadhasivam wrote:
>>> Add devicetree support for Mediatek X20 Development Board by Archermind.
>>> This board is based on the Deca-Core MT6797 SoC from Mediatek and is
>>> one of the 96Boards Consumer Edition platform.
>>>
>>> With this devicetree change, board can boot into initramfs.
>>>
>>> More information about this board can be found in 96Boards product page:
>>> https://www.96boards.org/product/mediatek-x20/
>>>
>>> Manivannan Sadhasivam (2):
>>> dt-bindings: Add vendor prefix for ArcherMind
>>> arm64: dts: Add Mediatek X20 Development Board support
>>>
>>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>>> arch/arm64/boot/dts/mediatek/Makefile | 1 +
>>> .../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
>>> 3 files changed, 35 insertions(+)
>>> create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
>>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox