[PATCH 0/5] Support for LEGO MINDSTORTMS EV3

[PATCH 0/5] Support for LEGO MINDSTORTMS EV3

[David Lechner]

This patch series adds support for LEGO MINDSTORTMS EV3[1]. This is a TI AM1808
based board.

This patch series has been tested working (along with some hacks to fix the
GPIOs) on an EV3.

There are still quite a few additional new drivers that need to be submitted
to get everything working. This patch series just adds support for the parts
that already have mainline kernel drivers.

I have a plan/driver in progress for many of the components[2], but I could use
some advice on a few particulars.

Bluetooth: This needs a driver to sequence a GPIO to take the Bluetooth chip
out of shutdown *after* the Bluetooth clock has been configured and started.
Is there a generic driver that can do this sort of thing? Or, if not, which
subsystem should the new driver go in?

Input and output ports: These ports are capable of hotplugging various devices,
such as sensors and motors. I have written a driver for these that can detect
most devices. I created a new subsystem for this called `lego-port`. However,
I am wondering if the existing phy or extcon subsystems might be a good fit for
this sort of thing.


[1]: http://mindstorms.lego.com
[2]: https://github.com/ev3dev/lego-linux-drivers/tree/master/evb

David Lechner (5):
  ARM: davinci: Compile MMC in kernel
  ARM: davinci: Don't append git rev to local version
  ARM: davinci: enable gpio poweroff in default config
  ARM: davinci: enable LEDs default-on trigger in default config
  ARM: dts: Add LEGO MINDSTORTMS EV3 dts

 arch/arm/boot/dts/Makefile             |   3 +-
 arch/arm/boot/dts/lego-ev3.dts         | 454 +++++++++++++++++++++++++++++++++
 arch/arm/configs/davinci_all_defconfig |   8 +-
 3 files changed, 462 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/dts/lego-ev3.dts

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] ARM: davinci: Compile MMC in kernel

[David Lechner]

This changes the davinci default configuration to compile the davinci
MMC driver into the kernel. This allows booting from an SD card without
requiring an initrd containing the kernel module.

Signed-off-by: David Lechner <david@lechnology.com>
---
 arch/arm/configs/davinci_all_defconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 58d04f1..a2f89a3 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -169,9 +169,9 @@ CONFIG_USB_MASS_STORAGE=m
 CONFIG_USB_G_SERIAL=m
 CONFIG_USB_G_PRINTER=m
 CONFIG_USB_CDC_COMPOSITE=m
-CONFIG_MMC=m
+CONFIG_MMC=y
 # CONFIG_MMC_BLOCK_BOUNCE is not set
-CONFIG_MMC_DAVINCI=m
+CONFIG_MMC_DAVINCI=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=m
 CONFIG_LEDS_GPIO=m
-- 
2.7.4

Re: [PATCH 1/5] ARM: davinci: Compile MMC in kernel

[Sekhar Nori]

On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
> This changes the davinci default configuration to compile the davinci
> MMC driver into the kernel. This allows booting from an SD card without
> requiring an initrd containing the kernel module.
> 
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>

"build" is more relevant here than "compile" so I changed that. And also
used davinci_all_defconfig as detailed in last e-mail.

Applied to v4.10/defconfig

Thanks,
Sekhar
--
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

[PATCH 2/5] ARM: davinci: Don't append git rev to local version

[David Lechner]

In the davinci default configuration, don't append the git revision to
the local kernel version by. This seems like the more desirable default
value.

Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
---
 arch/arm/configs/davinci_all_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index a2f89a3..9254609 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -1,3 +1,4 @@
+# CONFIG_LOCALVERSION_AUTO is not set
 # CONFIG_SWAP is not set
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] ARM: davinci: Don't append git rev to local version

[Sekhar Nori]

On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
> In the davinci default configuration, don't append the git revision to
> the local kernel version by. This seems like the more desirable default
> value.

Why? To the contrary I actually quite like the fact that the git commit
is appended to version string. Makes it easy for me to cross-check that
I am booting the right image.

> 
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>

Thanks,
Sekhar
--
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

Re: [PATCH 2/5] ARM: davinci: Don't append git rev to local version

[David Lechner]

On 10/24/2016 06:35 AM, Sekhar Nori wrote:
> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>> In the davinci default configuration, don't append the git revision to
>> the local kernel version by. This seems like the more desirable default
>> value.
>
> Why? To the contrary I actually quite like the fact that the git commit
> is appended to version string. Makes it easy for me to cross-check that
> I am booting the right image.
>
>>
>> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
>
> Thanks,
> Sekhar
>

Each time you make a commit, you get a new version, which installs 
another copy of the kernel modules on the device. This will fill up the 
SD card if you are making many commits.

Also, if someone wants to build the mainline kernel using the default 
configuration, it seems odd to have a git revision tacked on to the end 
even though you made no revisions.


--
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

Re: [PATCH 2/5] ARM: davinci: Don't append git rev to local version

[Sekhar Nori]

On Monday 24 October 2016 08:45 PM, David Lechner wrote:
> On 10/24/2016 06:35 AM, Sekhar Nori wrote:
>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>> In the davinci default configuration, don't append the git revision to
>>> the local kernel version by. This seems like the more desirable default
>>> value.
>>
>> Why? To the contrary I actually quite like the fact that the git commit
>> is appended to version string. Makes it easy for me to cross-check that
>> I am booting the right image.
>>
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>
>> Thanks,
>> Sekhar
>>
> 
> Each time you make a commit, you get a new version, which installs
> another copy of the kernel modules on the device. This will fill up the
> SD card if you are making many commits.

Right, but thats easily fixable by removing existing modules before
installing new ones.

> Also, if someone wants to build the mainline kernel using the default
> configuration, it seems odd to have a git revision tacked on to the end
> even though you made no revisions.

If you checkout a tag and build, then no commit information is added.
Which I guess is what most end users will do.

I don't see this done in other defconfigs like omap2plus and multi_v7 as
well. I would like to keep it similar for davinci.

Thanks,
Sekhar

Re: [PATCH 2/5] ARM: davinci: Don't append git rev to local version

[David Lechner]

On 10/26/2016 05:54 AM, Sekhar Nori wrote:
> On Monday 24 October 2016 08:45 PM, David Lechner wrote:
>> On 10/24/2016 06:35 AM, Sekhar Nori wrote:
>>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>>> In the davinci default configuration, don't append the git revision to
>>>> the local kernel version by. This seems like the more desirable default
>>>> value.
>>>
>>> Why? To the contrary I actually quite like the fact that the git commit
>>> is appended to version string. Makes it easy for me to cross-check that
>>> I am booting the right image.
>>>
>>>>
>>>> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
>>>
>>> Thanks,
>>> Sekhar
>>>
>>
>> Each time you make a commit, you get a new version, which installs
>> another copy of the kernel modules on the device. This will fill up the
>> SD card if you are making many commits.
>
> Right, but thats easily fixable by removing existing modules before
> installing new ones.
>
>> Also, if someone wants to build the mainline kernel using the default
>> configuration, it seems odd to have a git revision tacked on to the end
>> even though you made no revisions.
>
> If you checkout a tag and build, then no commit information is added.
> Which I guess is what most end users will do.
>
> I don't see this done in other defconfigs like omap2plus and multi_v7 as
> well. I would like to keep it similar for davinci.
>
> Thanks,
> Sekhar
>

OK, I will drop this patch.
--
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

[PATCH 3/5] ARM: davinci: enable gpio poweroff in default config

[David Lechner]

The gpio-poweroff driver is needed by LEGO MINDSTORMS EV3 (AM1808 based
board).

Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
---
 arch/arm/configs/davinci_all_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 9254609..9d7f0bc 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -117,6 +117,8 @@ CONFIG_SPI_DAVINCI=m
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_GPIO_SYSFS=y
 CONFIG_GPIO_PCA953X=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO=y
 CONFIG_WATCHDOG=y
 CONFIG_DAVINCI_WATCHDOG=m
 CONFIG_MFD_DM355EVM_MSP=y
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] ARM: davinci: enable gpio poweroff in default config

[Sekhar Nori]

On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
> The gpio-poweroff driver is needed by LEGO MINDSTORMS EV3 (AM1808 based
> board).
> 
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>

For defconfig patches, we have been using the davinci_all_defconfig
prefix (see git log --oneline arch/arm/configs/davinci_all_defconfig).

Applied to v4.10/defconfig with subject line changed to:

"ARM: davinci_all_defconfig: enable gpio poweroff driver"

Thanks,
Sekhar
--
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

[PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[David Lechner]

This adds a device tree definition file for LEGO MINDSTORMS EV3.

What is working:

* Pin muxing
* MicroSD card reader
* UART on input port 1

What is partially working:

* Buttons - working after GPIO fix
* LEDs - working after GPIO fix
* Poweroff/reset - working after GPIO fix
* Flash memory - driver loads but can't read the block devices - this is
  probably due to the fact that we are not able to configure the SPI to
  use DMA via device tree
* EEPROM - there seems to be a hardware bug that causes the first byte
  read to be corrupted - this can be worked around by adding an I2C stop
  between writing the register and reading the data, but the at24 driver
  does not have an option to do this

What is not working/to be added later:

* Display - waiting for "tiny DRM" to be mainlined
* Speaker - needs new PWM sound driver
* USB - waiting for OHCI and MUSB device tree support to be mainlined
* ADC - needs new iio driver
* GPIOs - broken because of recent changes to core gpio driver
* Bluetooth - needs new driver for sequencing power/enable/clock
* Input and output ports - need some sort of new phy or extcon driver
* Battery - needs new power supply driver (depends on ADC iio driver)

Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
---
 arch/arm/boot/dts/Makefile     |   3 +-
 arch/arm/boot/dts/lego-ev3.dts | 454 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 456 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/lego-ev3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f80f5b7..5f91c1a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -116,7 +116,8 @@ dtb-$(CONFIG_ARCH_CLPS711X) += \
 dtb-$(CONFIG_ARCH_DAVINCI) += \
 	da850-lcdk.dtb \
 	da850-enbw-cmc.dtb \
-	da850-evm.dtb
+	da850-evm.dtb \
+	lego-ev3.dtb
 dtb-$(CONFIG_ARCH_DIGICOLOR) += \
 	cx92755_equinox.dtb
 dtb-$(CONFIG_ARCH_EFM32) += \
diff --git a/arch/arm/boot/dts/lego-ev3.dts b/arch/arm/boot/dts/lego-ev3.dts
new file mode 100644
index 0000000..a6b4c7d
--- /dev/null
+++ b/arch/arm/boot/dts/lego-ev3.dts
@@ -0,0 +1,454 @@
+/*
+ * Device tree for LEGO MINDSTORMS EV3
+ *
+ * Copyright (C) 2016 David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation, version 2.
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+
+#include "da850.dtsi"
+
+/ {
+	compatible = "lego,ev3", "ti,da850";
+	model = "LEGO MINDSTORMS EV3";
+
+	soc@1c00000 {
+		/*
+		 * (ab)using pinctrl-single to disable all internal pullups/
+		 * pulldowns on I/O.
+		 */
+		pinmux@22c00c {
+			compatible = "pinctrl-single";
+			reg = <0x22c00c 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			pinctrl-single,bit-per-mux;
+			pinctrl-single,register-width = <32>;
+			pinctrl-single,function-mask = <0xf>;
+			/*
+			 * There is a bug in pinctrl-single that prevents us
+			 * from setting function-mask to 1, so doing things
+			 * in groups of 4. Doesn't really matter since we are
+			 * disabling all at once anyway.
+			 */
+
+			pinctrl-names = "default";
+			pinctrl-0 = <&pupu_disable>;
+
+			pupu_disable: pinmux_all_pins {
+				pinctrl-single,bits = <
+					0x0 0x00000000 0xffffffff
+				>;
+			};
+		};
+	};
+
+	/*
+	 * The buttons on the EV3 are mapped to keyboard keys.
+	 */
+	gpio_keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		label = "EV3 buttons";
+		pinctrl-names = "default";
+		pinctrl-0 = <&button_pins>;
+
+		enter {
+			label = "EV3 Button ENTER";
+			linux,code = <KEY_ENTER>;
+			gpios = <&gpio 29 GPIO_ACTIVE_HIGH>;
+		};
+		left {
+			label = "EV3 Button LEFT";
+			linux,code = <KEY_LEFT>;
+			gpios = <&gpio 102 GPIO_ACTIVE_HIGH>;
+		};
+		back {
+			label = "EV3 Button BACK";
+			linux,code = <KEY_BACKSPACE>;
+			gpios = <&gpio 106 GPIO_ACTIVE_HIGH>;
+		};
+		right {
+			label = "EV3 Button RIGHT";
+			linux,code = <KEY_RIGHT>;
+			gpios = <&gpio 124 GPIO_ACTIVE_HIGH>;
+		};
+		down {
+			label = "EV3 Button DOWN";
+			linux,code = <KEY_DOWN>;
+			gpios = <&gpio 126 GPIO_ACTIVE_HIGH>;
+		};
+		up {
+			label = "EV3 Button UP";
+			linux,code = <KEY_UP>;
+			gpios = <&gpio 127 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	/*
+	 * The EV3 has two built-in bi-color LEDs behind the buttons.
+	 */
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&led_pins>;
+
+		left_red {
+			label = "led1:red:brick-status";
+			/* GP6[13] */
+			gpios = <&gpio 103 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "default-on";
+		};
+		left_green {
+			label = "led1:green:brick-status";
+			/* GP6[7] */
+			gpios = <&gpio 108 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "default-on";
+		};
+		right_red {
+			label = "led2:red:brick-status";
+			/* GP6[12] */
+			gpios = <&gpio 109 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "default-on";
+		};
+		right_green {
+			label = "led2:green:brick-status";
+			/* GP6[14] */
+			gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "default-on";
+		};
+	};
+
+	/*
+	 * The EV3 is powered down by turning off the main 5V supply.
+	 */
+	gpio-poweroff {
+		compatible = "gpio-poweroff";
+		/* low signal powers off the board */
+		gpios = <&gpio 107 GPIO_ACTIVE_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&system_power_pin>;
+	};
+
+	/*
+	 * The Bluetooth chip requires a clock at 32768Hz. One of the PWMs
+	 * is used to generate this signal.
+	 */
+	bt-slow-clock {
+		status = "disabled";
+		compatible = "pwm-clock";
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "slow_clk";
+		pwms = <&ecap2 0 30517>;
+	};
+};
+
+&pmx_core {
+	status = "okay";
+
+	spi0_cs3_pin: pinmux_spi0_cs3_pin {
+		pinctrl-single,bits = <
+			/* CS3 */
+			0xc 0x01000000 0x0f000000
+		>;
+	};
+	mmc0_cd_pin: pinmux_mmc0_cd {
+		pinctrl-single,bits = <
+			/* GP5[14] */
+			0x2C 0x00000080 0x000000f0
+		>;
+	};
+	button_pins: pinmux_button_pins {
+		pinctrl-single,bits = <
+			/* GP1[13] */
+			0x8 0x00000800 0x00000f00
+			/* GP6[10] */
+			0x34 0x00800000 0x00f00000
+			/* GP6[6] */
+			0x38 0x00000080 0x000000f0
+			/* GP7[12], GP7[14], GP7[15] */
+			0x40 0x00808800 0x00f0ff00
+		>;
+	};
+	led_pins: pinmux_led_pins {
+		pinctrl-single,bits = <
+			/* GP6[12], GP6[13], GP6[14] */
+			0x34 0x00008880 0x0000fff0
+			/* GP6[7] */
+			0x38 0x00000008 0x0000000f
+		>;
+	};
+	system_power_pin: pinmux_system_power {
+		pinctrl-single,bits = <
+			/* GP6[11] */
+			0x34 0x00080000 0x000f0000
+		>;
+	};
+	in1_pins: pinmux_in1_pins {
+		pinctrl-single,bits = <
+			/* GP0[15] */
+			0x0 0x00000008 0x0000000f
+			/* GP0[2] */
+			0x4 0x00800000 0x00f00000
+			/* GP2[2] */
+			0x18 0x00800000 0x00f00000
+			/* GP8[10], GP8[11] */
+			0x48 0x88000000 0xff000000
+		>;
+	};
+	in2_pins: pinmux_in2_pins {
+		pinctrl-single,bits = <
+			/* GP0[13], GP0[14] */
+			0x0 0x00000880 0x00000ff0
+			/* GP8[12], GP8[14], GP8[15] */
+			0x48 0x00808800 0x00f0ff00
+		>;
+	};
+	in3_pins: pinmux_in3_pins {
+		pinctrl-single,bits = <
+			/* GP0[12] */
+			0x0 0x00008000 0x0000f000
+			/* GP1[14] */
+			0x8 0x00000080 0x000000f0
+			/* GP7[11] */
+			0x40 0x08000000 0x0f000000
+			/* GP7[9] */
+			0x44 0x00000008 0x0000000f
+			/* GP8[9] */
+			0x4c 0x00000008 0x0000000f
+		>;
+	};
+	in4_pins: pinmux_in4_pins {
+		pinctrl-single,bits = <
+			/* GP0[1] */
+			0x4 0x08000000 0x0f000000
+			/* GP1[15] */
+			0x8 0x00000008 0x0000000f
+			/* GP7[10] */
+			0x40 0x80000000 0xf0000000
+			/* GP7[8] */
+			0x44 0x00000080 0x000000f0
+			/* GP6[4] */
+			0x4c 0x00000800 0x00000f00
+		>;
+	};
+	outa_pins: pinmux_outa_pins {
+		pinctrl-single,bits = <
+			/* GP0[4] */
+			0x4 0x00008000 0x0000f000
+			/* GP3[15] */
+			0x1c 0x00000008 0x0000000f
+			/* GP3[6] */
+			0x20 0x00000080 0x000000f0
+			/* GP5[11] */
+			0x2c 0x00080000 0x000f0000
+			/* GP5[4] */
+			0x30 0x00008000 0x0000f000
+		>;
+	};
+	outb_pins: pinmux_outb_pins {
+		pinctrl-single,bits = <
+			/* GP0[3] */
+			0x4 0x00080000 0x000f0000
+			/* GP2[9] */
+			0x14 0x08000000 0x0f000000
+			/* GP2[1], GP2[5] */
+			0x18 0x08000800 0x0f000f00
+			/* GP5[11] */
+			0x2c 0x80000000 0xf0000000
+		>;
+	};
+	outc_pins: pinmux_outc_pins {
+		pinctrl-single,bits = <
+			/* GP3[8], GP3[14] */
+			0x1c 0x80000080 0xf00000f0
+			/* GP5[9], GP5[13] */
+			0x2c 0x08000800 0x0f000f00
+			/* GP6[8] */
+			0x34 0x80000000 0xf0000000
+		>;
+	};
+	outd_pins: pinmux_outd_pins {
+		pinctrl-single,bits = <
+			/* GP2[8] */
+			0x14 0x80000000 0xf0000000
+			/* GP5[10], GP5[15] */
+			0x2c 0x00800008 0x00f0000f
+			/* GP5[3] */
+			0x30 0x00080000 0x000f0000
+			/* GP6[9] */
+			0x34 0x08000000 0x0f000000
+		>;
+	};
+	sound_pins: pinmux_sound_pins {
+		pinctrl-single,bits = <
+			/* GP6[15] */
+			0x34 0x00000008 0x0000000f
+		>;
+	};
+	usb11_pins: pinmux_usb11_pins {
+		pinctrl-single,bits = <
+			/* GP6[5] */
+			0x40 0x00000080 0x000000f0
+			/* GP6[3] */
+			0x4c 0x00008000 0x0000f000
+		>;
+	};
+};
+
+/* Input port 2 */
+&serial0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&serial0_rxtx_pins>;
+};
+
+/* Input port 1 */
+&serial1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&serial1_rxtx_pins>;
+};
+
+/* Bluetooth */
+&serial2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&serial2_rxtx_pins>, <&serial2_rtscts_pins>;
+};
+
+&rtc0 {
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins>;
+
+	/*
+	 * EEPROM contains the first stage bootloader, HW ID and Bluetooth MAC.
+	 */
+	eeprom@50 {
+		compatible = "at24,24c128";
+		pagesize = <64>;
+		read-only;
+		reg = <0x50>;
+	};
+};
+
+&wdt {
+	status = "okay";
+};
+
+&mmc0 {
+	status = "okay";
+	max-frequency = <50000000>;
+	bus-width = <4>;
+	cd-gpios = <&gpio 94 GPIO_ACTIVE_LOW>;
+	cap-sd-highspeed;
+	cap-mmc-highspeed;
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin>;
+};
+
+&ehrpwm0 {
+	status = "okay";
+	pinctrl-names = "default";
+	/* SOUND_ARMA */
+	pinctrl-0 = <&ehrpwm0b_pins>;
+};
+
+&ehrpwm1 {
+	status = "disabled";
+	pinctrl-names = "default";
+	/* MBPWM, MAPWM */
+	pinctrl-0 = <&ehrpwm1a_pins>, <&ehrpwm1b_pins>;
+};
+
+&ecap0 {
+	status = "okay";
+	pinctrl-names = "default";
+	/* MCPWM */
+	pinctrl-0 = <&ecap0_pins>;
+};
+
+&ecap1 {
+	status = "disabled";
+	pinctrl-names = "default";
+	/* MDPWM */
+	pinctrl-0 = <&ecap1_pins>;
+};
+
+&ecap2 {
+	status = "disabled";
+	pinctrl-names = "default";
+	/* BTSLOWCLK */
+	pinctrl-0 = <&ecap2_pins>;
+};
+
+&spi0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
+	dmas = <&edma0 14 0>, <&edma0 15 0>;
+	dma-names = "rx", "tx";
+
+	spi-flash@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "n25q128a13", "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+		ti,spi-wdelay = <8>;
+
+		partition@0 {
+			label = "U-Boot";
+			reg = <0 0x40000>;
+		};
+
+		partition@40000 {
+			label = "U-Boot Env";
+			reg = <0x40000 0x10000>;
+		};
+
+		partition@50000 {
+			label = "Kernel";
+			reg = <0x50000 0x200000>;
+		};
+
+		partition@250000 {
+			label = "Filesystem";
+			reg = <0x250000 0xa50000>;
+		};
+
+		partition@cb0000 {
+			label = "Storage";
+			reg = <0xcb0000 0x2f0000>;
+		};
+	};
+
+	/* TODO: ADC goes here */
+};
+
+&spi1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi1_pins>, <&spi1_cs0_pin>;
+
+	/* TODO: LCD Display goes here */
+};
+
+&gpio {
+	status = "okay";
+};
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[Kevin Hilman]

David Lechner <david@lechnology.com> writes:

> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>
> What is working:
>
> * Pin muxing
> * MicroSD card reader
> * UART on input port 1
>
> What is partially working:
>
> * Buttons - working after GPIO fix
> * LEDs - working after GPIO fix
> * Poweroff/reset - working after GPIO fix
> * Flash memory - driver loads but can't read the block devices - this is
>   probably due to the fact that we are not able to configure the SPI to
>   use DMA via device tree
> * EEPROM - there seems to be a hardware bug that causes the first byte
>   read to be corrupted - this can be worked around by adding an I2C stop
>   between writing the register and reading the data, but the at24 driver
>   does not have an option to do this
>
> What is not working/to be added later:
>
> * Display - waiting for "tiny DRM" to be mainlined
> * Speaker - needs new PWM sound driver
> * USB - waiting for OHCI and MUSB device tree support to be mainlined
> * ADC - needs new iio driver
> * GPIOs - broken because of recent changes to core gpio driver
> * Bluetooth - needs new driver for sequencing power/enable/clock
> * Input and output ports - need some sort of new phy or extcon driver
> * Battery - needs new power supply driver (depends on ADC iio driver)
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>  arch/arm/boot/dts/Makefile     |   3 +-
>  arch/arm/boot/dts/lego-ev3.dts | 454 +++++++++++++++++++++++++++++++++++++++++

nit: can you name this da850-lego-ev3.dts

Though it's not very strictly enforced, we *try* to use the form
<soc>-<board>.dts.

Kevin

Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[Sekhar Nori]

On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
> This adds a device tree definition file for LEGO MINDSTORMS EV3.

Thanks for the patch!

> 
> What is working:
> 
> * Pin muxing
> * MicroSD card reader
> * UART on input port 1
> 
> What is partially working:
> 
> * Buttons - working after GPIO fix
> * LEDs - working after GPIO fix
> * Poweroff/reset - working after GPIO fix

Is the GPIO fix something that will go in v4.9-rc cycle ?

> * Flash memory - driver loads but can't read the block devices - this is
>   probably due to the fact that we are not able to configure the SPI to
>   use DMA via device tree

Hmm, I would not have expected PIO mode to be so inefficient that you
are unable to even read the block device.

> * EEPROM - there seems to be a hardware bug that causes the first byte
>   read to be corrupted - this can be worked around by adding an I2C stop
>   between writing the register and reading the data, but the at24 driver
>   does not have an option to do this
> 
> What is not working/to be added later:
> 
> * Display - waiting for "tiny DRM" to be mainlined
> * Speaker - needs new PWM sound driver
> * USB - waiting for OHCI and MUSB device tree support to be mainlined
> * ADC - needs new iio driver
> * GPIOs - broken because of recent changes to core gpio driver
> * Bluetooth - needs new driver for sequencing power/enable/clock
> * Input and output ports - need some sort of new phy or extcon driver
> * Battery - needs new power supply driver (depends on ADC iio driver)
> 
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
> ---
>  arch/arm/boot/dts/Makefile     |   3 +-
>  arch/arm/boot/dts/lego-ev3.dts | 454 +++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 456 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/lego-ev3.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f80f5b7..5f91c1a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -116,7 +116,8 @@ dtb-$(CONFIG_ARCH_CLPS711X) += \
>  dtb-$(CONFIG_ARCH_DAVINCI) += \
>  	da850-lcdk.dtb \
>  	da850-enbw-cmc.dtb \
> -	da850-evm.dtb
> +	da850-evm.dtb \
> +	lego-ev3.dtb
>  dtb-$(CONFIG_ARCH_DIGICOLOR) += \
>  	cx92755_equinox.dtb
>  dtb-$(CONFIG_ARCH_EFM32) += \
> diff --git a/arch/arm/boot/dts/lego-ev3.dts b/arch/arm/boot/dts/lego-ev3.dts
> new file mode 100644
> index 0000000..a6b4c7d
> --- /dev/null
> +++ b/arch/arm/boot/dts/lego-ev3.dts
> @@ -0,0 +1,454 @@
> +/*
> + * Device tree for LEGO MINDSTORMS EV3
> + *
> + * Copyright (C) 2016 David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation, version 2.
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/pwm/pwm.h>
> +
> +#include "da850.dtsi"
> +
> +/ {
> +	compatible = "lego,ev3", "ti,da850";
> +	model = "LEGO MINDSTORMS EV3";
> +
> +	soc@1c00000 {
> +		/*
> +		 * (ab)using pinctrl-single to disable all internal pullups/
> +		 * pulldowns on I/O.
> +		 */
> +		pinmux@22c00c {
> +			compatible = "pinctrl-single";
> +			reg = <0x22c00c 0x4>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			pinctrl-single,bit-per-mux;
> +			pinctrl-single,register-width = <32>;
> +			pinctrl-single,function-mask = <0xf>;
> +			/*
> +			 * There is a bug in pinctrl-single that prevents us
> +			 * from setting function-mask to 1, so doing things
> +			 * in groups of 4. Doesn't really matter since we are
> +			 * disabling all at once anyway.
> +			 */
> +
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pupu_disable>;
> +
> +			pupu_disable: pinmux_all_pins {
> +				pinctrl-single,bits = <
> +					0x0 0x00000000 0xffffffff
> +				>;
> +			};

Sigh. This is quite an abuse :)

I know we don't have a good way to configure this in kernel today. And I
am surprised we never had to care about disabling pullups so far. Can
you clarify why you need it? I assume there is some contention you want
to avoid, but on which interface?

I dont think this can be done this way using pinctrl-single. A small
driver to handle pullup/down control for da850 may have to be added to
drivers/pinctrl. It will be better to check with Linus Walleij on his
thoughts using a new thread ccing the pinctrl subsystem list as well.

[...]

> +	in1_pins: pinmux_in1_pins {
> +		pinctrl-single,bits = <
> +			/* GP0[15] */
> +			0x0 0x00000008 0x0000000f
> +			/* GP0[2] */
> +			0x4 0x00800000 0x00f00000
> +			/* GP2[2] */
> +			0x18 0x00800000 0x00f00000
> +			/* GP8[10], GP8[11] */
> +			0x48 0x88000000 0xff000000
> +		>;
> +	};

I see that this is not really used. Can you add these when you actually
use them. Looks like that applies to some other definitions like this below.

> +&ehrpwm1 {
> +	status = "disabled";

Hmm, disabled? Can you add this node when you actually use it?

> +	pinctrl-names = "default";
> +	/* MBPWM, MAPWM */
> +	pinctrl-0 = <&ehrpwm1a_pins>, <&ehrpwm1b_pins>;
> +};
> +
> +&ecap1 {
> +	status = "disabled";

same here and other places below.

> +	pinctrl-names = "default";
> +	/* MDPWM */
> +	pinctrl-0 = <&ecap1_pins>;
> +};
> +
> +&spi0 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
> +	dmas = <&edma0 14 0>, <&edma0 15 0>;
> +	dma-names = "rx", "tx";
> +
> +	spi-flash@0 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "n25q128a13", "jedec,spi-nor";
> +		reg = <0>;
> +		spi-max-frequency = <50000000>;
> +		ti,spi-wdelay = <8>;
> +
> +		partition@0 {
> +			label = "U-Boot";
> +			reg = <0 0x40000>;

Thats 256KB for U-Boot and MLO (I assume in concatenated AIS image). Is
that sufficient for future too? Moving partitions later is tough ask
because that means users will lose data when they upgrade the kernel
because of partitions moving around. Just a suggestion to keep future
U-Boot bloat in mind and not use a "just fits" number.

> +		};
> +
> +		partition@40000 {
> +			label = "U-Boot Env";
> +			reg = <0x40000 0x10000>;
> +		};
> +
> +		partition@50000 {
> +			label = "Kernel";
> +			reg = <0x50000 0x200000>;
> +		};
> +
> +		partition@250000 {
> +			label = "Filesystem";
> +			reg = <0x250000 0xa50000>;
> +		};
> +
> +		partition@cb0000 {
> +			label = "Storage";
> +			reg = <0xcb0000 0x2f0000>;
> +		};
> +	};
> +
> +	/* TODO: ADC goes here */

I would drop this comment.

> +};
> +
> +&spi1 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi1_pins>, <&spi1_cs0_pin>;
> +
> +	/* TODO: LCD Display goes here */

Add this node when you actually have display working.

Thanks,
Sekhar
--
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

Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[David Lechner]

On 10/24/2016 06:58 AM, Sekhar Nori wrote:
> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>
> Thanks for the patch!
>
>>
>> What is working:
>>
>> * Pin muxing
>> * MicroSD card reader
>> * UART on input port 1
>>
>> What is partially working:
>>
>> * Buttons - working after GPIO fix
>> * LEDs - working after GPIO fix
>> * Poweroff/reset - working after GPIO fix
>
> Is the GPIO fix something that will go in v4.9-rc cycle ?

Not sure. This is still being discussed.

http://www.gossamer-threads.com/lists/linux/kernel/2550178

>
>> * Flash memory - driver loads but can't read the block devices - this is
>>   probably due to the fact that we are not able to configure the SPI to
>>   use DMA via device tree
>
> Hmm, I would not have expected PIO mode to be so inefficient that you
> are unable to even read the block device.

I am getting a -EIO error. I haven't been able to trace down exactly 
what is causing it yet though.

>
...
>> +/ {
>> +	compatible = "lego,ev3", "ti,da850";
>> +	model = "LEGO MINDSTORMS EV3";
>> +
>> +	soc@1c00000 {
>> +		/*
>> +		 * (ab)using pinctrl-single to disable all internal pullups/
>> +		 * pulldowns on I/O.
>> +		 */
>> +		pinmux@22c00c {
>> +			compatible = "pinctrl-single";
>> +			reg = <0x22c00c 0x4>;
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			pinctrl-single,bit-per-mux;
>> +			pinctrl-single,register-width = <32>;
>> +			pinctrl-single,function-mask = <0xf>;
>> +			/*
>> +			 * There is a bug in pinctrl-single that prevents us
>> +			 * from setting function-mask to 1, so doing things
>> +			 * in groups of 4. Doesn't really matter since we are
>> +			 * disabling all at once anyway.
>> +			 */
>> +
>> +			pinctrl-names = "default";
>> +			pinctrl-0 = <&pupu_disable>;
>> +
>> +			pupu_disable: pinmux_all_pins {
>> +				pinctrl-single,bits = <
>> +					0x0 0x00000000 0xffffffff
>> +				>;
>> +			};
>
> Sigh. This is quite an abuse :)
>
> I know we don't have a good way to configure this in kernel today. And I
> am surprised we never had to care about disabling pullups so far. Can
> you clarify why you need it? I assume there is some contention you want
> to avoid, but on which interface?

The EV3 was designed with external pullup/pulldown everywhere. I know 
for certain that it breaks one of the buttons if you do not disable the 
internal ones. I imagine that it would have subtle effects elsewhere if 
they are not disabled.

I have not gone through each pullup/pulldown bank individually, but it 
would not surprise me at all if there was at least one thing on most of 
them that would be adversely affected.

>
> I dont think this can be done this way using pinctrl-single. A small
> driver to handle pullup/down control for da850 may have to be added to
> drivers/pinctrl. It will be better to check with Linus Walleij on his
> thoughts using a new thread ccing the pinctrl subsystem list as well.

I will be glad to try to make a driver, but when I ran into this problem 
I could not find much information on how to handle banks of 
pullup/pulldown. Most of what I saw was for ones that can be 
individually controlled. If anyone knows something like this already 
that I could look at, it would be helpful to me.


> [...]
>
>> +	in1_pins: pinmux_in1_pins {
>> +		pinctrl-single,bits = <
>> +			/* GP0[15] */
>> +			0x0 0x00000008 0x0000000f
>> +			/* GP0[2] */
>> +			0x4 0x00800000 0x00f00000
>> +			/* GP2[2] */
>> +			0x18 0x00800000 0x00f00000
>> +			/* GP8[10], GP8[11] */
>> +			0x48 0x88000000 0xff000000
>> +		>;
>> +	};
>
> I see that this is not really used. Can you add these when you actually
> use them. Looks like that applies to some other definitions like this below.

It will be possible to uses these gpios via sysfs (until a proper driver 
for input and output ports is merged). So how about I attach these to 
the gpio node for now?

>
>> +&ehrpwm1 {
>> +	status = "disabled";
>
> Hmm, disabled? Can you add this node when you actually use it?

Not sure why I have this disabled. Like the gpios, the pwms can be used 
via sysfs, so I would like to leave them.

>
>> +	pinctrl-names = "default";
>> +	/* MBPWM, MAPWM */
>> +	pinctrl-0 = <&ehrpwm1a_pins>, <&ehrpwm1b_pins>;
>> +};
>> +
>> +&ecap1 {
>> +	status = "disabled";
>
> same here and other places below.
>
>> +	pinctrl-names = "default";
>> +	/* MDPWM */
>> +	pinctrl-0 = <&ecap1_pins>;
>> +};
>> +
>> +&spi0 {
>> +	status = "okay";
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
>> +	dmas = <&edma0 14 0>, <&edma0 15 0>;
>> +	dma-names = "rx", "tx";
>> +
>> +	spi-flash@0 {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		compatible = "n25q128a13", "jedec,spi-nor";
>> +		reg = <0>;
>> +		spi-max-frequency = <50000000>;
>> +		ti,spi-wdelay = <8>;
>> +
>> +		partition@0 {
>> +			label = "U-Boot";
>> +			reg = <0 0x40000>;
>
> Thats 256KB for U-Boot and MLO (I assume in concatenated AIS image). Is
> that sufficient for future too? Moving partitions later is tough ask
> because that means users will lose data when they upgrade the kernel
> because of partitions moving around. Just a suggestion to keep future
> U-Boot bloat in mind and not use a "just fits" number.

The MLO is on an EEPROM in the EV3, so the U-Boot partition is just 
U-boot. The SoC boots from I2C, which then runs whatever is as 0x0 on 
the flash memory.

This partition table matches the partition scheme used on the official 
LEGO firmware that ships with the devices. Most people running their own 
kernel will probably be loading it from a microSD card, leaving the 
official firmware intact and therefore will always have this partition 
table.

My thinking is that if someone does want to use a different partitioning 
scheme, they can build their own U-Boot and configure it to modify the 
device tree with a new partition table.

The way the LEGO firmware flashing utility works, it wipes out the 
entire flash memory each time you flash the firmware. So, data loss is 
not a concern - you will loose your data anyway.

>
>> +		};
>> +
>> +		partition@40000 {
>> +			label = "U-Boot Env";
>> +			reg = <0x40000 0x10000>;
>> +		};
>> +
>> +		partition@50000 {
>> +			label = "Kernel";
>> +			reg = <0x50000 0x200000>;
>> +		};
>> +
>> +		partition@250000 {
>> +			label = "Filesystem";
>> +			reg = <0x250000 0xa50000>;
>> +		};
>> +
>> +		partition@cb0000 {
>> +			label = "Storage";
>> +			reg = <0xcb0000 0x2f0000>;
>> +		};
>> +	};
>> +
>> +	/* TODO: ADC goes here */
>
> I would drop this comment.

ack

>
>> +};
>> +
>> +&spi1 {
>> +	status = "okay";
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&spi1_pins>, <&spi1_cs0_pin>;
>> +
>> +	/* TODO: LCD Display goes here */
>
> Add this node when you actually have display working.

What if we set this up as a spidev node instead? This way the display 
could be used from userspace without a driver.



--
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

Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[David Lechner]

On 10/24/2016 10:50 AM, David Lechner wrote:
> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>
>>> +&ehrpwm1 {
>>> +    status = "disabled";
>>
>> Hmm, disabled? Can you add this node when you actually use it?
>
> Not sure why I have this disabled. Like the gpios, the pwms can be used
> via sysfs, so I would like to leave them.
>

Now I remember why these are disabled. The clock matching is broken. 
Only the first ehrpwm and the first ecap get clocks. The others fail.

I can change these to "okay". It will just result in a kernel error 
message until the clocks are fixed.

Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[David Lechner]

On 10/24/2016 02:50 PM, David Lechner wrote:
> On 10/24/2016 10:50 AM, David Lechner wrote:
>> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>>
>>>> +&ehrpwm1 {
>>>> +    status = "disabled";
>>>
>>> Hmm, disabled? Can you add this node when you actually use it?
>>
>> Not sure why I have this disabled. Like the gpios, the pwms can be used
>> via sysfs, so I would like to leave them.
>>
>
> Now I remember why these are disabled. The clock matching is broken.
> Only the first ehrpwm and the first ecap get clocks. The others fail.
>
> I can change these to "okay". It will just result in a kernel error
> message until the clocks are fixed.
>

correction: it is not the clocks that are broken. it is the device names.

In  arch/arm/mach-davinci/da8xx-dt.c, we have...


	OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm", NULL),
	OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm", NULL),
	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap", NULL),
	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap", NULL),
	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap", NULL),


Which causes each device to have the same device node name. This causes 
sysfs errors because it is trying to register a second device at the 
same sysfs path.

If you change the names here, then the device do not work because the 
clock lookup fails.

--
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

Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[Sekhar Nori]

On Tuesday 25 October 2016 02:50 AM, David Lechner wrote:
> On 10/24/2016 02:50 PM, David Lechner wrote:
>> On 10/24/2016 10:50 AM, David Lechner wrote:
>>> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>>>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>>>
>>>>> +&ehrpwm1 {
>>>>> +    status = "disabled";
>>>>
>>>> Hmm, disabled? Can you add this node when you actually use it?
>>>
>>> Not sure why I have this disabled. Like the gpios, the pwms can be used
>>> via sysfs, so I would like to leave them.
>>>
>>
>> Now I remember why these are disabled. The clock matching is broken.
>> Only the first ehrpwm and the first ecap get clocks. The others fail.
>>
>> I can change these to "okay". It will just result in a kernel error
>> message until the clocks are fixed.
>>
> 
> correction: it is not the clocks that are broken. it is the device names.
> 
> In  arch/arm/mach-davinci/da8xx-dt.c, we have...
> 
> 
>     OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm", NULL),
>     OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm", NULL),
>     OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap", NULL),
>     OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap", NULL),
>     OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap", NULL),
> 
> 
> Which causes each device to have the same device node name. This causes
> sysfs errors because it is trying to register a second device at the
> same sysfs path.
> 
> If you change the names here, then the device do not work because the
> clock lookup fails.

Yeah, this is incorrect (I should have caught it in review). The device
id should have been present in the lookup. Can you fix auxdata and clock
lookup too and send a separate patch? Its probably a v4.9-rc candidate.

Thanks,
Sekhar
--
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

Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[David Lechner]

On 10/25/2016 05:58 AM, Sekhar Nori wrote:
> On Tuesday 25 October 2016 02:50 AM, David Lechner wrote:
>> On 10/24/2016 02:50 PM, David Lechner wrote:
>>> On 10/24/2016 10:50 AM, David Lechner wrote:
>>>> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>>>>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>>>>
>>>>>> +&ehrpwm1 {
>>>>>> +    status = "disabled";
>>>>>
>>>>> Hmm, disabled? Can you add this node when you actually use it?
>>>>
>>>> Not sure why I have this disabled. Like the gpios, the pwms can be used
>>>> via sysfs, so I would like to leave them.
>>>>
>>>
>>> Now I remember why these are disabled. The clock matching is broken.
>>> Only the first ehrpwm and the first ecap get clocks. The others fail.
>>>
>>> I can change these to "okay". It will just result in a kernel error
>>> message until the clocks are fixed.
>>>
>>
>> correction: it is not the clocks that are broken. it is the device names.
>>
>> In  arch/arm/mach-davinci/da8xx-dt.c, we have...
>>
>>
>>     OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm", NULL),
>>     OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm", NULL),
>>     OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap", NULL),
>>     OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap", NULL),
>>     OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap", NULL),
>>
>>
>> Which causes each device to have the same device node name. This causes
>> sysfs errors because it is trying to register a second device at the
>> same sysfs path.
>>
>> If you change the names here, then the device do not work because the
>> clock lookup fails.
>
> Yeah, this is incorrect (I should have caught it in review). The device
> id should have been present in the lookup. Can you fix auxdata and clock
> lookup too and send a separate patch? Its probably a v4.9-rc candidate.
>
> Thanks,
> Sekhar
>

Yes, I can do this.


--
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

Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[David Lechner]

On 10/24/2016 10:50 AM, David Lechner wrote:
> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>> +};
>>> +
>>> +&spi1 {
>>> +    status = "okay";
>>> +    pinctrl-names = "default";
>>> +    pinctrl-0 = <&spi1_pins>, <&spi1_cs0_pin>;
>>> +
>>> +    /* TODO: LCD Display goes here */
>>
>> Add this node when you actually have display working.
>
> What if we set this up as a spidev node instead? This way the display
> could be used from userspace without a driver.
>

To answer my own question, it seems that specifying "spidev" in 
devicetree is frowned upon since it does not "describe the hardware".

Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[Sekhar Nori]

On Monday 24 October 2016 09:20 PM, David Lechner wrote:
> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>>
>> Thanks for the patch!
>>
>>>
>>> What is working:
>>>
>>> * Pin muxing
>>> * MicroSD card reader
>>> * UART on input port 1
>>>
>>> What is partially working:
>>>
>>> * Buttons - working after GPIO fix
>>> * LEDs - working after GPIO fix
>>> * Poweroff/reset - working after GPIO fix
>>
>> Is the GPIO fix something that will go in v4.9-rc cycle ?
> 
> Not sure. This is still being discussed.
> 
> http://www.gossamer-threads.com/lists/linux/kernel/2550178
> 
>>
>>> * Flash memory - driver loads but can't read the block devices - this is
>>>   probably due to the fact that we are not able to configure the SPI to
>>>   use DMA via device tree
>>
>> Hmm, I would not have expected PIO mode to be so inefficient that you
>> are unable to even read the block device.
> 
> I am getting a -EIO error. I haven't been able to trace down exactly
> what is causing it yet though.

Okay. Seems unrelated to DMA though. Will check the status of SPI on my
DA850 EVM once I get the chance.

> 
>>
> ...
>>> +/ {
>>> +    compatible = "lego,ev3", "ti,da850";
>>> +    model = "LEGO MINDSTORMS EV3";
>>> +
>>> +    soc@1c00000 {
>>> +        /*
>>> +         * (ab)using pinctrl-single to disable all internal pullups/
>>> +         * pulldowns on I/O.
>>> +         */
>>> +        pinmux@22c00c {
>>> +            compatible = "pinctrl-single";
>>> +            reg = <0x22c00c 0x4>;
>>> +            #address-cells = <1>;
>>> +            #size-cells = <0>;
>>> +            pinctrl-single,bit-per-mux;
>>> +            pinctrl-single,register-width = <32>;
>>> +            pinctrl-single,function-mask = <0xf>;
>>> +            /*
>>> +             * There is a bug in pinctrl-single that prevents us
>>> +             * from setting function-mask to 1, so doing things
>>> +             * in groups of 4. Doesn't really matter since we are
>>> +             * disabling all at once anyway.
>>> +             */
>>> +
>>> +            pinctrl-names = "default";
>>> +            pinctrl-0 = <&pupu_disable>;
>>> +
>>> +            pupu_disable: pinmux_all_pins {
>>> +                pinctrl-single,bits = <
>>> +                    0x0 0x00000000 0xffffffff
>>> +                >;
>>> +            };
>>
>> Sigh. This is quite an abuse :)
>>
>> I know we don't have a good way to configure this in kernel today. And I
>> am surprised we never had to care about disabling pullups so far. Can
>> you clarify why you need it? I assume there is some contention you want
>> to avoid, but on which interface?
> 
> The EV3 was designed with external pullup/pulldown everywhere. I know
> for certain that it breaks one of the buttons if you do not disable the
> internal ones. I imagine that it would have subtle effects elsewhere if
> they are not disabled.
> 
> I have not gone through each pullup/pulldown bank individually, but it
> would not surprise me at all if there was at least one thing on most of
> them that would be adversely affected.
> 
>>
>> I dont think this can be done this way using pinctrl-single. A small
>> driver to handle pullup/down control for da850 may have to be added to
>> drivers/pinctrl. It will be better to check with Linus Walleij on his
>> thoughts using a new thread ccing the pinctrl subsystem list as well.
> 
> I will be glad to try to make a driver, but when I ran into this problem
> I could not find much information on how to handle banks of
> pullup/pulldown. Most of what I saw was for ones that can be
> individually controlled. If anyone knows something like this already
> that I could look at, it would be helpful to me.

pinctrl-single supports a different compatible "pinconf-single" which
supports the pinconf interface that can be used to set pullup and
pulldown bias.

Unfortunately, in case of AM18x, there are two registers to touch:
PUPD_ENA and PUPD_SEL. So I believe the pinctrl-single driver cannot be
used.

There are pinconf operations pin_config_group_{set|get}(). Based on
documentation these are meant to act on a group of pins. There are quite
a few drivers implementing this interface. Perhaps they can be used as
an example.

Also, this needs to be done in a way that can be used by other boards
too, so please move the common properties to da850.dtsi. Only the board
specific pullup/down configuration should be in this file.

> 
> 
>> [...]
>>
>>> +    in1_pins: pinmux_in1_pins {
>>> +        pinctrl-single,bits = <
>>> +            /* GP0[15] */
>>> +            0x0 0x00000008 0x0000000f
>>> +            /* GP0[2] */
>>> +            0x4 0x00800000 0x00f00000
>>> +            /* GP2[2] */
>>> +            0x18 0x00800000 0x00f00000
>>> +            /* GP8[10], GP8[11] */
>>> +            0x48 0x88000000 0xff000000
>>> +        >;
>>> +    };
>>
>> I see that this is not really used. Can you add these when you actually
>> use them. Looks like that applies to some other definitions like this
>> below.
> 
> It will be possible to uses these gpios via sysfs (until a proper driver
> for input and output ports is merged). So how about I attach these to
> the gpio node for now?

pins are usually attached to the node that consumes the GPIO pins, not
to the gpio node itself.

If the pins are not connected to anything and can be used via gpio
sysfs, then "pinctrl hog" or "board level pinmux" is to be used.
Something like below:

+&pmx_core {
+       pinctrl-names = "default";
+       pinctrl-0 = <&in1_pins>;
+
+       in1_pins: pinmux_in1_pins {
+               pinctrl-single,bits = <
+                       0x0 0x00000008 0x0000000f
+			...
+               >;
+       };
+};

That said, device tree is supposed to describe hardware and not change
depend on current driver support. So I would wait for the driver to get
merged before merging the pins that are used by it. It looks like you
wont be able to use the support in a meaningful way till then anyway.

> 
>>
>>> +&ehrpwm1 {
>>> +    status = "disabled";
>>
>> Hmm, disabled? Can you add this node when you actually use it?
> 
> Not sure why I have this disabled. Like the gpios, the pwms can be used
> via sysfs, so I would like to leave them.

Okay, then please keep the node enabled.

> 
>>
>>> +    pinctrl-names = "default";
>>> +    /* MBPWM, MAPWM */
>>> +    pinctrl-0 = <&ehrpwm1a_pins>, <&ehrpwm1b_pins>;
>>> +};
>>> +
>>> +&ecap1 {
>>> +    status = "disabled";
>>
>> same here and other places below.
>>
>>> +    pinctrl-names = "default";
>>> +    /* MDPWM */
>>> +    pinctrl-0 = <&ecap1_pins>;
>>> +};
>>> +
>>> +&spi0 {
>>> +    status = "okay";
>>> +    pinctrl-names = "default";
>>> +    pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
>>> +    dmas = <&edma0 14 0>, <&edma0 15 0>;
>>> +    dma-names = "rx", "tx";
>>> +
>>> +    spi-flash@0 {
>>> +        #address-cells = <1>;
>>> +        #size-cells = <1>;
>>> +        compatible = "n25q128a13", "jedec,spi-nor";
>>> +        reg = <0>;
>>> +        spi-max-frequency = <50000000>;
>>> +        ti,spi-wdelay = <8>;
>>> +
>>> +        partition@0 {
>>> +            label = "U-Boot";
>>> +            reg = <0 0x40000>;
>>
>> Thats 256KB for U-Boot and MLO (I assume in concatenated AIS image). Is
>> that sufficient for future too? Moving partitions later is tough ask
>> because that means users will lose data when they upgrade the kernel
>> because of partitions moving around. Just a suggestion to keep future
>> U-Boot bloat in mind and not use a "just fits" number.
> 
> The MLO is on an EEPROM in the EV3, so the U-Boot partition is just
> U-boot. The SoC boots from I2C, which then runs whatever is as 0x0 on
> the flash memory.

okay.

> This partition table matches the partition scheme used on the official
> LEGO firmware that ships with the devices. Most people running their own
> kernel will probably be loading it from a microSD card, leaving the
> official firmware intact and therefore will always have this partition
> table.
> 
> My thinking is that if someone does want to use a different partitioning
> scheme, they can build their own U-Boot and configure it to modify the
> device tree with a new partition table.
> 
> The way the LEGO firmware flashing utility works, it wipes out the
> entire flash memory each time you flash the firmware. So, data loss is
> not a concern - you will loose your data anyway.

Alright, thanks for the detailed explanation.

Thanks,
Sekhar

Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[David Lechner]

On 10/24/2016 06:58 AM, Sekhar Nori wrote:
> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>
> Thanks for the patch!
>
>>
>> What is working:
>>
>> * Pin muxing
>> * MicroSD card reader
>> * UART on input port 1
>>
>> What is partially working:
>>
>> * Buttons - working after GPIO fix
>> * LEDs - working after GPIO fix
>> * Poweroff/reset - working after GPIO fix
>
> Is the GPIO fix something that will go in v4.9-rc cycle ?
>

FYI, the fix is in linux-gpio/fixes now.

--
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

Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts

[Sekhar Nori]

On Thursday 27 October 2016 07:00 AM, David Lechner wrote:
> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>>
>> Thanks for the patch!
>>
>>>
>>> What is working:
>>>
>>> * Pin muxing
>>> * MicroSD card reader
>>> * UART on input port 1
>>>
>>> What is partially working:
>>>
>>> * Buttons - working after GPIO fix
>>> * LEDs - working after GPIO fix
>>> * Poweroff/reset - working after GPIO fix
>>
>> Is the GPIO fix something that will go in v4.9-rc cycle ?
>>
> 
> FYI, the fix is in linux-gpio/fixes now.

Thanks, I added the patch to my 'acked' branch which has stuff useful
for testing on davinci but not going through my tree. It gets merged
into my master branch so that branch can be used for all mach-davinci
development.

Thanks,
Sekhar

[PATCH 4/5] ARM: davinci: enable LEDs default-on trigger in default config

[David Lechner]

The LEDs default-on trigger is nice to have. For example, it can be used
to configure a LED as a power indicator.

Signed-off-by: David Lechner <david@lechnology.com>
---
 arch/arm/configs/davinci_all_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 9d7f0bc..e380743 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -181,6 +181,7 @@ CONFIG_LEDS_GPIO=m
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=m
 CONFIG_LEDS_TRIGGER_HEARTBEAT=m
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_OMAP=m
 CONFIG_DMADEVICES=y
-- 
2.7.4

Re: [PATCH 4/5] ARM: davinci: enable LEDs default-on trigger in default config

[Sekhar Nori]

On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
> The LEDs default-on trigger is nice to have. For example, it can be used
> to configure a LED as a power indicator.
> 
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>  arch/arm/configs/davinci_all_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
> index 9d7f0bc..e380743 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -181,6 +181,7 @@ CONFIG_LEDS_GPIO=m
>  CONFIG_LEDS_TRIGGERS=y
>  CONFIG_LEDS_TRIGGER_TIMER=m
>  CONFIG_LEDS_TRIGGER_HEARTBEAT=m
> +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y

Can this be module like rest of the triggers? It will come on later, but
not sure if you care about the difference that much. Having it a module
will be better for those boards that don't need it.

Thanks,
Sekhar

Re: [PATCH 4/5] ARM: davinci: enable LEDs default-on trigger in default config

[David Lechner]

On 10/27/2016 06:29 AM, Sekhar Nori wrote:
> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>> The LEDs default-on trigger is nice to have. For example, it can be used
>> to configure a LED as a power indicator.
>>
>> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
>> ---
>>  arch/arm/configs/davinci_all_defconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
>> index 9d7f0bc..e380743 100644
>> --- a/arch/arm/configs/davinci_all_defconfig
>> +++ b/arch/arm/configs/davinci_all_defconfig
>> @@ -181,6 +181,7 @@ CONFIG_LEDS_GPIO=m
>>  CONFIG_LEDS_TRIGGERS=y
>>  CONFIG_LEDS_TRIGGER_TIMER=m
>>  CONFIG_LEDS_TRIGGER_HEARTBEAT=m
>> +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
>
> Can this be module like rest of the triggers? It will come on later, but
> not sure if you care about the difference that much. Having it a module
> will be better for those boards that don't need it.
>
> Thanks,
> Sekhar
>

Yes, module is OK here.
--
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

Re: [PATCH 4/5] ARM: davinci: enable LEDs default-on trigger in default config

[Sekhar Nori]

On Thursday 27 October 2016 09:19 PM, David Lechner wrote:
> Yes, module is OK here.

Here is the patch I pushed to v4.10/defconfig.

Thanks,
Sekhar

---8<---
From: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
Date: Fri, 21 Oct 2016 13:36:56 -0500
Subject: [PATCH] ARM: davinci_all_defconfig: enable LED default-on trigger

The LEDs default-on trigger is nice to have. For example, it can be used
to configure a LED as a power indicator.

Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
[nsekhar-l0cyMroinI0@public.gmane.org: build as module, subject line fixes]
Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
---
 arch/arm/configs/davinci_all_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 513978eaf03d..b5e978ff177f 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -180,6 +180,7 @@ CONFIG_LEDS_GPIO=m
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=m
 CONFIG_LEDS_TRIGGER_HEARTBEAT=m
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=m
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_OMAP=m
 CONFIG_DMADEVICES=y
-- 
2.9.0



--
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

Re: [PATCH 0/5] Support for LEGO MINDSTORTMS EV3

[Lennart Sorensen]

On Fri, Oct 21, 2016 at 01:36:52PM -0500, David Lechner wrote:
> This patch series adds support for LEGO MINDSTORTMS EV3[1]. This is a TI AM1808
> based board.
> 
> This patch series has been tested working (along with some hacks to fix the
> GPIOs) on an EV3.
> 
> There are still quite a few additional new drivers that need to be submitted
> to get everything working. This patch series just adds support for the parts
> that already have mainline kernel drivers.
> 
> I have a plan/driver in progress for many of the components[2], but I could use
> some advice on a few particulars.
> 
> Bluetooth: This needs a driver to sequence a GPIO to take the Bluetooth chip
> out of shutdown *after* the Bluetooth clock has been configured and started.
> Is there a generic driver that can do this sort of thing? Or, if not, which
> subsystem should the new driver go in?
> 
> Input and output ports: These ports are capable of hotplugging various devices,
> such as sensors and motors. I have written a driver for these that can detect
> most devices. I created a new subsystem for this called `lego-port`. However,
> I am wondering if the existing phy or extcon subsystems might be a good fit for
> this sort of thing.

Both this cover and patch 5/5 has MINDSTORTMS instead of MINDSTORMS in
a few places (including the subject line).

-- 
Len Sorensen