From: Javier Martinez Canillas <hidden> Date: 2012-11-30 10:09:14
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patch-set adds initial device
tree support for these devices.
The device tree allows to boot from an MMC/SD and are working all
the components that already have device tree support on OMAP3 SoCs:
- MMC/SD
- UARTs
- GPIO LEDs
- TWL4030 codec audio
- pinmux/pinconf pinctrl
Some peripheral are still not working such as Flash storage and
Ethernet but support for these will also be included once the
OMAP GPMC device tree binding patches hit mainline.
This is a v2 of the patch-set that solves issues pointed out by
Enric Balletbo and it is composed of the following patches:
[PATCH v2 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices
[PATCH v2 2/3] ARM/dts: omap3: Add support for IGEPv2 board
[PATCH v2 3/3] ARM/dts: omap3: Add support for IGEP COM Module
Best regards,
Javier
From: Javier Martinez Canillas <hidden> Date: 2012-11-30 10:09:17
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT on OMAP3
SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio and pinctrl based mux).
Signed-off-by: Javier Martinez Canillas <redacted>
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
---
Changes since v1:
- Use default-state = "on" instead default-trigger = "default-on" for LED
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-igep0020.dts | 56 ++++++++++++++++++++++++++++++++++
2 files changed, 57 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0020.dts
From: Javier Martinez Canillas <hidden> Date: 2012-11-30 10:09:20
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas <redacted>
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
---
Changes since v1:
- Use default-state = "on" instead default-trigger = "default-on" for LED
- Update GPIO mapping according to latest IGEP COM Module rev.E instead D
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-igep0030.dts | 44 ++++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0030.dts
2012/11/30 Javier Martinez Canillas [off-list ref]:
quoted hunk
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT on OMAP3
SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio and pinctrl based mux).
Signed-off-by: Javier Martinez Canillas <redacted>
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
---
Changes since v1:
- Use default-state = "on" instead default-trigger = "default-on" for LED
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-igep0020.dts | 56 ++++++++++++++++++++++++++++++++++
2 files changed, 57 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0020.dts
2012/11/30 Javier Martinez Canillas [off-list ref]:
quoted hunk
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas <redacted>
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
---
Changes since v1:
- Use default-state = "on" instead default-trigger = "default-on" for LED
- Update GPIO mapping according to latest IGEP COM Module rev.E instead D
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-igep0030.dts | 44 ++++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0030.dts
Hi Javier,
On 11/30/2012 11:08 AM, Javier Martinez Canillas wrote:
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patch-set adds initial device
tree support for these devices.
The device tree allows to boot from an MMC/SD and are working all
the components that already have device tree support on OMAP3 SoCs:
That's cool to have one more board DT converted.
That series looks good to me, I just have a comment on the DT mux stuff.
Regards,
Benoit
- MMC/SD
- UARTs
- GPIO LEDs
- TWL4030 codec audio
- pinmux/pinconf pinctrl
Some peripheral are still not working such as Flash storage and
Ethernet but support for these will also be included once the
OMAP GPMC device tree binding patches hit mainline.
This is a v2 of the patch-set that solves issues pointed out by
Enric Balletbo and it is composed of the following patches:
[PATCH v2 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices
[PATCH v2 2/3] ARM/dts: omap3: Add support for IGEPv2 board
[PATCH v2 3/3] ARM/dts: omap3: Add support for IGEP COM Module
Best regards,
Javier
BTW, in this case, the UART3 does not seems to have any connection with
the pins settings. Sine your don't have it in the pmx_core you should
have it in side the UART3 node.
&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&uart3_pins>;
};
The rational is that, the mux will be done only if the driver is probed
and not unconditionally during pmx_core probe like it will be the case
otherwise.
Regards,
Benoit
Tony made a comment to avoid associating these data inside the pmx_core
and instead do that in the dedicated device part.
Hi Benoit,
Thanks a lot for your feedback.
I didn't know about this convention, the OMAP mcspi1_cs2 pin is configured in
gpio_176 mode (OMAP_MUX_MODE4) because this GPIO line is used as the SMSC9221
LAN Ethernet controller IRQ.
But since the ethernet chip is connected to the OMAP3 processor thourgh its GPMC
and the DT support for GPMC is still not merged in mainline, DT support this
this pheripheral is still missing on this initial DT.
So, I'll just removes mcbsp2_pins for now and this can be added again on the
ethernet device part once support for this pheripheral is added.
BTW, in this case, the UART3 does not seems to have any connection with
the pins settings. Sine your don't have it in the pmx_core you should
have it in side the UART3 node.
&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&uart3_pins>;
};
Yes, I missed that. Thanks for pointing this out.
The rational is that, the mux will be done only if the driver is probed
and not unconditionally during pmx_core probe like it will be the case
otherwise.
Regards,
Benoit
I'll post a v3 with your suggestions.
Thanks a lot and best regards,
Javier