[PATCH 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Add palmas node and omap specific palmas regulator properties.
This patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.11/dts
Boot tested on omap5-uevm board.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 145 ++
1 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..88172db 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -254,6 +254,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
+
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = 220;
+ regulator-max-microvolt = 220;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt
[PATCH 1/2] ARM: dts: add dtsi for palmas
Adds palmas mfd and palmas regulator nodes.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/palmas.dtsi | 98 +
1 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/palmas.dtsi
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
new file mode 100644
index 000..4c5162f
--- /dev/null
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -0,0 +1,98 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/interrupt-controller/irq.h
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = ldo2;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-name = ldo3;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-name = ldo4;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-name = ldo5;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-name = ldo6;
+ };
+
+ ldo7_reg: ldo7 {
+ regulator-name = ldo7;
+ };
+
+ ldo8_reg: ldo8 {
+ regulator-name = ldo8;
+ };
+
+ ldo9_reg: ldo9 {
+ regulator-name = ldo9;
+ };
+
+ ldoln_reg: ldoln {
+ regulator-name = ldoln;
+ };
+
+ ldousb_reg: ldousb {
+ regulator-name = ldousb;
+ };
+ };
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: dts: Add palmas dtsi
This patch series adds palmas.dtsi and adds the omap5 specific palmas entries in the omap5-uevm board file. This patch series is based on: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm board. J Keerthy (2): ARM: dts: add dtsi for palmas ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties arch/arm/boot/dts/omap5-uevm.dts | 145 ++ arch/arm/boot/dts/palmas.dtsi| 98 + 2 files changed, 243 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/palmas.dtsi -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: hwmod data: Remove irq entries from mcspi, mmc hwmods
Commit '3b9b10151c6838af52244cec4af41a938bb5b7ec' cleaned up the
data file to remove all irq and dma entries for all hwmods, which
are now populated by DT. But mcspi and mmc irq, dma entries were
retained since MMC, NFS boot was not working. Since it is root caused
to be an issue with only DMA entries [1], irq can be safely removed.
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90115.html
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 54
1 file changed, 54 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 5f5d631..11e579b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1747,11 +1747,6 @@ static struct omap_hwmod_class
omap44xx_mcspi_hwmod_class = {
};
/* mcspi1 */
-static struct omap_hwmod_irq_info omap44xx_mcspi1_irqs[] = {
- { .irq = 65 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct omap_hwmod_dma_info omap44xx_mcspi1_sdma_reqs[] = {
{ .name = tx0, .dma_req = 34 + OMAP44XX_DMA_REQ_START },
{ .name = rx0, .dma_req = 35 + OMAP44XX_DMA_REQ_START },
@@ -1773,7 +1768,6 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
.name = mcspi1,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
- .mpu_irqs = omap44xx_mcspi1_irqs,
.sdma_reqs = omap44xx_mcspi1_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
@@ -1787,11 +1781,6 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
};
/* mcspi2 */
-static struct omap_hwmod_irq_info omap44xx_mcspi2_irqs[] = {
- { .irq = 66 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct omap_hwmod_dma_info omap44xx_mcspi2_sdma_reqs[] = {
{ .name = tx0, .dma_req = 42 + OMAP44XX_DMA_REQ_START },
{ .name = rx0, .dma_req = 43 + OMAP44XX_DMA_REQ_START },
@@ -1809,7 +1798,6 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
.name = mcspi2,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
- .mpu_irqs = omap44xx_mcspi2_irqs,
.sdma_reqs = omap44xx_mcspi2_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
@@ -1823,11 +1811,6 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
};
/* mcspi3 */
-static struct omap_hwmod_irq_info omap44xx_mcspi3_irqs[] = {
- { .irq = 91 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct omap_hwmod_dma_info omap44xx_mcspi3_sdma_reqs[] = {
{ .name = tx0, .dma_req = 14 + OMAP44XX_DMA_REQ_START },
{ .name = rx0, .dma_req = 15 + OMAP44XX_DMA_REQ_START },
@@ -1845,7 +1828,6 @@ static struct omap_hwmod omap44xx_mcspi3_hwmod = {
.name = mcspi3,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
- .mpu_irqs = omap44xx_mcspi3_irqs,
.sdma_reqs = omap44xx_mcspi3_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
@@ -1859,11 +1841,6 @@ static struct omap_hwmod omap44xx_mcspi3_hwmod = {
};
/* mcspi4 */
-static struct omap_hwmod_irq_info omap44xx_mcspi4_irqs[] = {
- { .irq = 48 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct omap_hwmod_dma_info omap44xx_mcspi4_sdma_reqs[] = {
{ .name = tx0, .dma_req = 69 + OMAP44XX_DMA_REQ_START },
{ .name = rx0, .dma_req = 70 + OMAP44XX_DMA_REQ_START },
@@ -1879,7 +1856,6 @@ static struct omap_hwmod omap44xx_mcspi4_hwmod = {
.name = mcspi4,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
- .mpu_irqs = omap44xx_mcspi4_irqs,
.sdma_reqs = omap44xx_mcspi4_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
@@ -1915,11 +1891,6 @@ static struct omap_hwmod_class omap44xx_mmc_hwmod_class
= {
};
/* mmc1 */
-static struct omap_hwmod_irq_info omap44xx_mmc1_irqs[] = {
- { .irq = 83 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct omap_hwmod_dma_info omap44xx_mmc1_sdma_reqs[] = {
{ .name = tx, .dma_req = 60 + OMAP44XX_DMA_REQ_START },
{ .name = rx, .dma_req = 61 + OMAP44XX_DMA_REQ_START },
@@ -1935,7 +1906,6 @@ static struct omap_hwmod omap44xx_mmc1_hwmod = {
.name = mmc1,
.class = omap44xx_mmc_hwmod_class,
.clkdm_name = l3_init_clkdm,
- .mpu_irqs = omap44xx_mmc1_irqs,
.sdma_reqs = omap44xx_mmc1_sdma_reqs,
.main_clk = hsmmc1_fclk,
.prcm = {
@@ -1949,11 +1919,6 @@ static struct omap_hwmod omap44xx_mmc1_hwmod = {
};
/* mmc2 */
-static struct omap_hwmod_irq_info omap44xx_mmc2_irqs[] = {
- { .irq = 86 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct
Re: Block layer / MMC: Order of segments in SG-list
On Sun, Jun 09 2013, Joel A Fernandes wrote: Hi, So I tried dumping addresses of an SG list in omap_hsmmc driver before it is passed to DMA. I found some interesting traces occasionally such as the below SG list of length 4. [6.758716] (0) length=4096, sg virt addr=c1318000, sg phy addr=81318000 [6.765863] (1) length=4096, sg virt addr=c1317000, sg phy addr=81317000 [6.773011] (2) length=4096, sg virt addr=c1316000, sg phy addr=81316000 [6.780087] (3) length=4096, sg virt addr=c1315000, sg phy addr=81315000 What is interesting is these chunks are really physically contiguous but in reverse order in the list. I think a smarter ordering can actually improve through put considerably and save precious DMA resources by not having to allocate slots for parts of contiguous chunk of physical memory. Is there any particular reason why this might be the case? I traced to find that the SG list is actually prepared by mmc_queue_map_sg - blk_rq_map_sg mmc or the block layer can't do much about the memory it is handed. The sg mappings just reflect the fact that they happened to be in reverse, so to speak. You are right in that having those pages in the right order and being able to merge the segments is a win. Unless you are heavily SG entry starved or your DMA controller has a high per-sg-entry overhead, it's usually not a big deal. That said, you should investigate WHY they are in that order :-) -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP v3.10-rc regressions that no one's fixed
Hi folks -- particularly TIers working on mainline,
There are several regressions that started with v3.10-rc that no one's
fixed for over a month. Some of them should be quite easy:
* 37xx EVM: boot fails
- as of v3.10-rc1
- Cause unknown
* 2420N800, 2430sdp: failed to get counter_32k resource
- omap2_sync32k_clocksource_init: failed to get counter_32k resource
- Cause unknown
* 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup
failure
- Cause unknown
- These IP blocks don't exist on OMAP3xxx/AM35xx chips
* 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure
- Cause unknown
(For more details, see the logs at the link below.)
It would be good if people could step up to fix these before v3.10 comes
out.
- Paul
-- Forwarded message --
Date: Mon, 10 Jun 2013 02:00:50 + (UTC)
From: Paul Walmsley p...@pwsan.com
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Subject: OMAP baseline test results for v3.10-rc5
Here are some basic OMAP test results for Linux v3.10-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc5/20130609031534/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a,
omap1_defconfig, omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only, omap2plus_defconfig,
omap2plus_defconfig_2430sdp_only
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig,
rmk_omap4430_sdp_oldconfig
Build: zImage:
Pass ( 1/ 1): omap2plus_defconfig
Boot to userspace:
FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
Pass ( 9/12): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 4430es2panda, 4460pandaes, 5912osk,
cmt3517
PM: chip retention via suspend:
FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda
Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes
PM: chip retention via dynamic idle:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM: chip off except CORE via suspend:
Pass ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle:
Pass ( 1/ 1): 3730beaglexm
PM: chip off via suspend:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
PM: chip off via dynamic idle:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
Failing tests: fixed by posted patches
--
(none)
Failing tests: needing investigation
Boot tests:
* 3517EVM CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
- Not currently part of the automated test suite
* 37xx EVM: boot fails
- as of v3.10-rc1
- Cause unknown
Boot warnings:
* 2420N800, 2430sdp: failed to get counter_32k resource
- omap2_sync32k_clocksource_init: failed to get counter_32k resource
- Cause unknown
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2
- Longstanding issue; does not occur on the 3517EVM
* 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup
failure
- Cause unknown
- These IP blocks don't exist on OMAP3xxx/AM35xx chips
* 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure
- Cause unknown
PM tests:
* 2430sdp: power domains not entering retention
- Cause unknown
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate (debug ignore_loglevel)
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
* 4430es2panda: pwrdm state mismatch on CAM, DSS
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
- http://marc.info/?l=linux-arm-kernelm=136432340618226w=2
* 4430es2panda: MPU, ABE didn't enter target state
- New for v3.10-rc
* 4460pandaes: pwrdm state mismatch on DSS, ABE, IVAHD, TESLA
* 4460pandaes: chip not entering retention in dynamic idle
- Presumably 4430es2panda also fails this
- Suspend-to-RAM enters full chip retention
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of
Re: [PATCH] ARM: dts: add dtsi for palmas
Totally agree to all the above concerns. So can we have a custom .dtsi file for a board+pmic combination? Or have only the required properties over ridden in the board file? The common approach is to only apply nodes and node properties to the .dtsi files which are appropriate for _all_ platforms which include them. Anything that is only relevant to a sub-set of boards should be in a higher ranking .dtsi file and finally, any settings which are board specific should be in the board's .dts file. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] ARM : omap3 : fix wrong container_of in clock36xx.c
2013/6/6 Paul Walmsley p...@pwsan.com: On Thu, 6 Jun 2013, jean-philippe francois wrote: Does the first version [1] of the patch, that only touch the MSB of the divider also trigger the bug ? [1] https://patchwork.kernel.org/patch/2609681/ That one passes the PM test here. Will take this one for v3.10-rc fixes instead, since it fixes a known DSS problem and the original code wasn't correct. Jean, could you work with Mike to come up with a better approach for v3.11 or v3.12? Hi, I am ok to work on it, however could you explain to me what is the expected output of your PM tests, and how to reproduce them ? The board I used to test the clock frequency was correct suffered from heavy handed oscilloscope probing and is currently out of order :( Jean-Philippe François. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap2 dss: omap_display_init: Dont allow more than the maximum number of displays.
Currently the maximum number of display is hardcoded in the array
omapfb2_device. Made the number a #define and check it in init routine.
Signed-off-by: Andreas Naumann anaum...@ultratronik.de
---
Our board supports a lot of panels and we could probably solve this more
effectively, but arrays shouldnt silently overflow when using more than 10
displays. Created the patch on 3.1 and tested it there. This one is rebased on
todays linux-omap.git
arch/arm/mach-omap2/display.c | 5 +
drivers/video/omap2/omapfb/omapfb.h | 10 +-
include/video/omapdss.h | 2 ++
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index ff37be1..6f1a147 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -338,6 +338,11 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
return -ENODEV;
}
+ if( board_data-num_devices OMAPFB_MAX_DISPLAY_NUM ){
+ pr_err(Trying to init more displays(%d) than possible.(%d)\n,
board_data-num_devices, OMAPFB_MAX_DISPLAY_NUM);
+ return -ENODEV;
+ }
+
board_data-version = ver;
board_data-dsi_enable_pads = omap_dsi_enable_pads;
board_data-dsi_disable_pads = omap_dsi_disable_pads;
diff --git a/drivers/video/omap2/omapfb/omapfb.h
b/drivers/video/omap2/omapfb/omapfb.h
index 623cd87..00d3fbc 100644
--- a/drivers/video/omap2/omapfb/omapfb.h
+++ b/drivers/video/omap2/omapfb/omapfb.h
@@ -96,15 +96,15 @@ struct omapfb2_device {
int state;
unsigned num_fbs;
- struct fb_info *fbs[10];
- struct omapfb2_mem_region regions[10];
+ struct fb_info *fbs[OMAPFB_MAX_DISPLAY_NUM];
+ struct omapfb2_mem_region regions[OMAPFB_MAX_DISPLAY_NUM];
unsigned num_displays;
- struct omapfb_display_data displays[10];
+ struct omapfb_display_data displays[OMAPFB_MAX_DISPLAY_NUM];
unsigned num_overlays;
- struct omap_overlay *overlays[10];
+ struct omap_overlay *overlays[OMAPFB_MAX_DISPLAY_NUM];
unsigned num_managers;
- struct omap_overlay_manager *managers[10];
+ struct omap_overlay_manager *managers[OMAPFB_MAX_DISPLAY_NUM];
struct workqueue_struct *auto_update_wq;
};
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index aeb4e9a..dfb054f 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -54,6 +54,8 @@
#define DISPC_IRQ_ACBIAS_COUNT_STAT3 (1 29)
#define DISPC_IRQ_FRAMEDONE3 (1 30)
+#define OMAPFB_MAX_DISPLAY_NUM 10
+
struct omap_dss_device;
struct omap_overlay_manager;
struct dss_lcd_mgr_config;
--
1.8.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Add palmas node and omap specific palmas regulator properties.
This patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.11/dts
There's no need for this to be in the commit message.
Boot tested on omap5-uevm board.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 145
++
1 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..88172db 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -254,6 +254,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
The interrupt property is fairly ubiqutous. There's not really any
need to document it in this manor.
+ interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
Use the IRQ includes in dt-bindings.
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
I'm a bit confused by this. Is it now common practice to break out
nodes in this way? I assume to counter mass indentation, but it's a
bit alien to me.
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
Are these all board specific, or are they shared with any other
platform?
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = 220;
+ regulator-max-microvolt = 220;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo5_reg: ldo5 {
+
Re: [PATCH v2 1/1] ARM : omap3 : fix wrong container_of in clock36xx.c
Hello Jean-Philippe, On Mon, 10 Jun 2013, jean-philippe francois wrote: I am ok to work on it, however could you explain to me what is the expected output of your PM tests, and how to reproduce them ? Here is the expected output for my ancient 3730 ES1.0 Beagle-XM: http://www.pwsan.com/omap/testlogs/test_v3.10-rc5/20130609031534/pm/3730beaglexm/3730beaglexm_log.txt When I ran that same test on the second version of your patch, the system froze during the retention dynamic idle test: %% Start retention dynamic idle UART wakeup test echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms root@beagleboard:~# root@beagleboard:~# echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms root@beagleboard:~# root@beagleboard:~# echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms root@beagleboard:~# root@beagleboard:~# echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms root@beagleboard:~# root@beagleboard:~# --- That is where the log stopped. Sorry to hear about your board - I can certainly sympathize, regards, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Hello Lee Jones,
-Original Message-
From: Lee Jones [mailto:lee.jo...@linaro.org]
Sent: Monday, June 10, 2013 1:42 PM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@wwwdotorg.org;
swar...@nvidia.com; sa...@linux.intel.com; g...@slimlogic.co.uk
Subject: Re: [PATCH 2/2] ARM: dts: OMAP5: add palmas node and omap
specific palmas regulator properties
Add palmas node and omap specific palmas regulator properties.
This patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-
omap-dt.git
for_3.11/dts
There's no need for this to be in the commit message.
Ok. I will remove this.
Boot tested on omap5-uevm board.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 145
++
1 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..88172db 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -254,6 +254,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
The interrupt property is fairly ubiqutous. There's not really any need
to document it in this manor.
+ interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
Use the IRQ includes in dt-bindings.
Oops Yes I will include.
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
I'm a bit confused by this. Is it now common practice to break out
nodes in this way? I assume to counter mass indentation, but it's a bit
alien to me.
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
Are these all board specific, or are they shared with any other
platform?
Yes. Hence moved all of them to board file as compared to my
Last approach when I had kept all of them under palmas.dtsi.
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+
Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
Hi Kevin, On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath hvaib...@ti.com AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I have tested BeagleBone boot with today's mainline bootloader and kernel. It boots perfectly fine. Thanks and regards, Lokesh I've also not been able to boot a mainline kernel on the BeagleBone for some time. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] ARM: dts: Add palmas dtsi
This patch series adds palmas.dtsi and adds the omap5 specific palmas entries in the omap5-uevm board file. This patch series is based on: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm board. J Keerthy (2): ARM: dts: add dtsi for palmas ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties arch/arm/boot/dts/omap5-uevm.dts | 147 ++ arch/arm/boot/dts/palmas.dtsi| 98 + 2 files changed, 245 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/palmas.dtsi -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Add palmas node and omap specific palmas regulator properties.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 147 ++
1 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..ffbcc3f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, active high level-sensitive */
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
+
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = 220;
+ regulator-max-microvolt = 220;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-min-microvolt = 150;
+
[PATCH v2 1/2] ARM: dts: add dtsi for palmas
Adds palmas mfd and palmas regulator nodes.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/palmas.dtsi | 98 +
1 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/palmas.dtsi
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
new file mode 100644
index 000..4c5162f
--- /dev/null
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -0,0 +1,98 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/interrupt-controller/irq.h
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = ldo2;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-name = ldo3;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-name = ldo4;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-name = ldo5;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-name = ldo6;
+ };
+
+ ldo7_reg: ldo7 {
+ regulator-name = ldo7;
+ };
+
+ ldo8_reg: ldo8 {
+ regulator-name = ldo8;
+ };
+
+ ldo9_reg: ldo9 {
+ regulator-name = ldo9;
+ };
+
+ ldoln_reg: ldoln {
+ regulator-name = ldoln;
+ };
+
+ ldousb_reg: ldousb {
+ regulator-name = ldousb;
+ };
+ };
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: dts: add dtsi for palmas
On Monday 10 June 2013 02:34 PM, J Keerthy wrote: Adds palmas mfd and palmas regulator nodes. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: J Keerthy j-keer...@ti.com --- arch/arm/boot/dts/palmas.dtsi | 98 + Hi Keerthy, Can you please add documentation for dt binding: Documentation/devicetree/bindings/mfd Most of time we refer from this document for dt population. Thanks, Laxman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
Hi Kevin, On 06/07/2013 09:31 PM, Nishanth Menon wrote: On 11:31-20130607, Kevin Hilman wrote: On most OMAP3 platforms, the twl4030 IRQ line is connected to the SYS_NIRQ line on OMAP. Add another DTS include file (twl4030_omap3.dtsi) for boards that hook up the twl4030 this way to include. This allows RTC wake from off-mode to work again on OMAP3-based platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM, 3530/Overo, 3730/Overo-STORM. Special thanks to Florian Vaussard for suggesting use of preprocessor feature. Cc: Florian Vaussard florian.vauss...@epfl.ch Cc: Benoit Cousson b-cous...@ti.com Cc: Nishanth Menon n...@ti.com Signed-off-by: Kevin Hilman khil...@linaro.org Thanks, Reviewed-by: Nishanth Menon n...@ti.com Thanks, I've just applied it in for_3.11/dts. Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c issue on Panda with DT boot, v3.10-rc4
On 07/06/13 21:39, Felipe Balbi wrote: sounds like there's something left in FIFO which is not getting read out, then we end up timing out. Can you try the patch below ? It's patch of a bigger patchset which I still need to clean a few things up, but they should be very close to being ready. IIRC, one of the patches creates a problem for N900 (only) which gets fixed later, I just need to combine those two patches into one to avoid the regression. diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index aa3b91e..471b434 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1022,9 +1022,8 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) } } while (stat); - omap_i2c_complete_cmd(dev, err); - out: + omap_i2c_complete_cmd(dev, err); spin_unlock_irqrestore(dev-lock, flags); return IRQ_HANDLED; With this change the boot becomes unreliable: [3.024322] V2V1: 2100 mV [4.049530] omap_i2c 4807.i2c: timeout waiting for bus ready [5.059417] omap_i2c 4807.i2c: timeout waiting for bus ready [5.059448] twl: Write failed (mod 9, reg 0xe5 count 1) and this continues. I did manage to boot once, and running i2cdump printed each byte very slowly, and with 0xff as the data. Tomi signature.asc Description: OpenPGP digital signature
RE: [PATCH v2 1/2] ARM: dts: add dtsi for palmas
Hi Laxman, -Original Message- From: Laxman Dewangan [mailto:ldewan...@nvidia.com] Sent: Monday, June 10, 2013 2:55 PM To: J, KEERTHY Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux- o...@vger.kernel.org; linux-ker...@vger.kernel.org; grant.lik...@secretlab.ca; swar...@wwwdotorg.org; Stephen Warren; sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org Subject: Re: [PATCH v2 1/2] ARM: dts: add dtsi for palmas On Monday 10 June 2013 02:34 PM, J Keerthy wrote: Adds palmas mfd and palmas regulator nodes. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: J Keerthy j-keer...@ti.com --- arch/arm/boot/dts/palmas.dtsi | 98 + Hi Keerthy, Can you please add documentation for dt binding: Documentation/devicetree/bindings/mfd https://lkml.org/lkml/2013/6/6/25 It is based on this. Most of time we refer from this document for dt population. Thanks, Laxman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c issue on Panda with DT boot, v3.10-rc4
On 07/06/13 21:36, Tony Lindgren wrote: Maybe check that the i2c related pins are muxed properly for your board with pinctrl-single? Reading the bytes individually with i2cget works fine, so I think that tells us that the pins are configured ok. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] ARM: dts: add dtsi for palmas
Hi Keerthy,
On 06/10/2013 06:03 AM, J, KEERTHY wrote:
Hi Stephen,
Thanks for the review comments.
From: Stephen Warren [swar...@wwwdotorg.org]
Sent: Saturday, June 08, 2013 1:26 AM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org;
linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/07/2013 05:28 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
+palmas {
Hmmm. That (i.e. requiring the board file to declare the node, then
setting up all the content by later including this file) is an
interesting approach. I guess it's reasonable. The one issue is that it
makes it a little harder for the board file to override any of the
properties in this file., although it certainly is possible by including
those overrides after the include.
Irrespective of that, some comments on this:
+ palmas_pmic {
+ ti,ldo6-vibrator;
For example, what if the board doesn't want to have the property set?
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
Or what if the board wants to limit the voltage range of this regulator
due to what it's used for on the board.
+ regulator-always-on;
+ regulator-boot-on;
And those two properties are almost certainly board-specific policy.
Totally agree to all the above concerns. So can we have a custom .dtsi file
for a board+pmic combination? Or have only the required properties over ridden
in the board file?
Yes, you can do that potentially if most OMAP5 boards will reuse the
same kind of settings. Kevin has just done that for OMAP3 + twl4030.
In this case, since we do have only one board, I'm not sure it worth the
effort.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
From: Tony Lindgren [t...@atomide.com]
Sent: Friday, June 07, 2013 11:50 PM
To: linus.wall...@linaro.org
Cc: devicetree-disc...@lists.ozlabs.org; Haojian Zhuang; Ujfalusi, Peter;
linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Quadros, Roger
Subject: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up
events
For wake-up events from deeper idle modes we need to check the
configured padconf registers for the wake-up bit and then call
the related interrupt handler.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/pinctrl/Makefile |3
drivers/pinctrl/pinctrl-single-omap.c | 287 +
include/linux/platform_data/pinctrl-single-omap.h |4
3 files changed, 293 insertions(+), 1 deletion(-)
create mode 100644 drivers/pinctrl/pinctrl-single-omap.c
create mode 100644 include/linux/platform_data/pinctrl-single-omap.h
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 9bdaeb8..abf7f01 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -30,7 +30,8 @@ obj-$(CONFIG_PINCTRL_NOMADIK) += pinctrl-nomadik.o
obj-$(CONFIG_PINCTRL_STN8815) += pinctrl-nomadik-stn8815.o
obj-$(CONFIG_PINCTRL_DB8500) += pinctrl-nomadik-db8500.o
obj-$(CONFIG_PINCTRL_DB8540) += pinctrl-nomadik-db8540.o
-obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
+pcs-$(CONFIG_ARCH_OMAP2PLUS) += pinctrl-single-omap.o
+obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o $(pcs-y)
obj-$(CONFIG_PINCTRL_SIRF) += pinctrl-sirf.o
obj-$(CONFIG_PINCTRL_SUNXI)+= pinctrl-sunxi.o
obj-$(CONFIG_PINCTRL_TEGRA)+= pinctrl-tegra.o
diff --git a/drivers/pinctrl/pinctrl-single-omap.c
b/drivers/pinctrl/pinctrl-single-omap.c
new file mode 100644
index 000..680cf81
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-single-omap.c
@@ -0,0 +1,287 @@
+/*
+ * pinctrl-single-omap - omap specific wake-up irq handler
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
snip
+
+static int __init pcs_omap_init(void)
+{
+ platform_driver_register(pcs_omap_soc_driver);
+ platform_driver_register(pcs_omap_driver);
+
+ return 0;
+}
+module_init(pcs_omap_init);
It seems this has to be moved to an earlier place (e.g. subsys_initcall)
else the pinctrl core fails to find the pinctrl device at the device creation
time and bails out with -EPROBE_DEFER. Also, that device is never
created again, so -EPROBE_DEFER doesn't seem to work there.
The code i'm talking about is in dt_to_map_one_config()
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/devicetree.c#n109
+
+static void __exit pcs_omap_exit(void)
+{
+ platform_driver_unregister(pcs_omap_driver);
+ platform_driver_unregister(pcs_omap_soc_driver);
+}
+module_exit(pcs_omap_exit);
+
+MODULE_ALIAS(platform: pinctrl-single-omap);
+MODULE_AUTHOR(Texas Instruments Inc.);
+MODULE_DESCRIPTION(pinctrl-single-omap driver);
+MODULE_LICENSE(GPL v2);
diff --git a/include/linux/platform_data/pinctrl-single-omap.h
b/include/linux/platform_data/pinctrl-single-omap.h
new file mode 100644
index 000..bd92efc
--- /dev/null
+++ b/include/linux/platform_data/pinctrl-single-omap.h
@@ -0,0 +1,4 @@
+struct pcs_omap_pdata {
+ int irq;
+ void (*reconfigure_io_chain)(void);
+};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
On Mon, 10 Jun 2013, J Keerthy wrote:
Add palmas node and omap specific palmas regulator properties.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 147
++
1 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..ffbcc3f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, active high level-sensitive */
I still think this is superfluous, especially now you're using the
defines which basically say the same thing.
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
+
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = 220;
+ regulator-max-microvolt = 220;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+
RE: [PATCH v2 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Hello Lee jones,
-Original Message-
From: Lee Jones [mailto:lee.jo...@linaro.org]
Sent: Monday, June 10, 2013 3:36 PM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@wwwdotorg.org;
swar...@nvidia.com; sa...@linux.intel.com; g...@slimlogic.co.uk
Subject: Re: [PATCH v2 2/2] ARM: dts: OMAP5: add palmas node and omap
specific palmas regulator properties
On Mon, 10 Jun 2013, J Keerthy wrote:
Add palmas node and omap specific palmas regulator properties.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 147
++
1 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..ffbcc3f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, active high level-sensitive */
I still think this is superfluous, especially now you're using the
defines which basically say the same thing.
I retained the whole comment as it was needed to specify IRQ# as 7
And thought it completely described the below interrupt property.
I can knock it off if it is totally unnecessary.
If there are no further comments. Can I add a Reviewed-by?
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N
*/
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
+
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+
RE: [PATCH] ARM: dts: add dtsi for palmas
Hi Benoit,
-Original Message-
From: Cousson, Benoit
Sent: Monday, June 10, 2013 3:00 PM
To: J, KEERTHY
Cc: Stephen Warren; devicetree-disc...@lists.ozlabs.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
Hi Keerthy,
On 06/10/2013 06:03 AM, J, KEERTHY wrote:
Hi Stephen,
Thanks for the review comments.
From: Stephen Warren [swar...@wwwdotorg.org]
Sent: Saturday, June 08, 2013 1:26 AM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org;
linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/07/2013 05:28 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is based on the
patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
diff --git a/arch/arm/boot/dts/palmas.dtsi
b/arch/arm/boot/dts/palmas.dtsi
+palmas {
Hmmm. That (i.e. requiring the board file to declare the node, then
setting up all the content by later including this file) is an
interesting approach. I guess it's reasonable. The one issue is that
it makes it a little harder for the board file to override any of the
properties in this file., although it certainly is possible by
including those overrides after the include.
Irrespective of that, some comments on this:
+ palmas_pmic {
+ ti,ldo6-vibrator;
For example, what if the board doesn't want to have the property set?
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
Or what if the board wants to limit the voltage range of this
regulator due to what it's used for on the board.
+ regulator-always-on;
+ regulator-boot-on;
And those two properties are almost certainly board-specific policy.
Totally agree to all the above concerns. So can we have a custom
.dtsi
file for a board+pmic combination? Or have only the required
properties over ridden in the board file?
Yes, you can do that potentially if most OMAP5 boards will reuse the
same kind of settings. Kevin has just done that for OMAP3 + twl4030.
In this case, since we do have only one board, I'm not sure it worth
the effort.
I sent a V2 with only the most generic property in palmas.dtsi and the
Configurable parameter under the board file. Let me know if that patch set
Is fine.
Regards,
Benoit
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. +- ti,i2c-slave-address - I2C slave address of the PMIC +- ti,i2c-voltage-register - I2C register address where voltage commands are + to be set. +- ti,i2c-command-register - I2C register address where commands are to be set + when OMAP enters low power state. This may be the same as + ti,i2c-voltage-register depending on the PMIC. +- ti,slew-rate-microvolt - worst case slew rate of rise / fall for voltage + transition in microvolts per microseconds (uV/uS) +- step-size-micro-volts - Step size in micovolts as to what one step in voltage + selector increment translates to. See example. +- regulator-min-microvolt - Minimum voltage in microvolts which is supported by + the PMIC in ti,step-size-microvolt increments. See example. +- regulator-max-microvolt - Maximum voltage in microvolts which is supported + by the PMIC in ti,step-size-microvolt increments. See example. The other thing is this whole business of encoding the properties of the PMIC in the DT like this. Paul Walmsley has started doing some work for some similiar hardware where instead of doing this the regulator is in the DT as normal and then the driver for the offloaded voltage scaling gets the information about the register layout from the regulator driver. This is a bit neater overall and would cope with determining which method to use at runtime. signature.asc Description: Digital signature
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On 07/06/13 20:50, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. What issue do you refer to? DSS does not have DT bindings, and removing DSS from hwmod data will break DSS for omap4. Tomi signature.asc Description: OpenPGP digital signature
RE: [PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
Hi Tony, (sorry, on Outlook web)
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
This change is not necessary if we make sure the pinctrl-single-omap driver
gets registered early enough, before the pinctrl devices are probed.
(e.g. subsys_initcall())
I've commented about this in the other patch.
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
From: Tony Lindgren [t...@atomide.com]
Sent: Friday, June 07, 2013 11:50 PM
To: linus.wall...@linaro.org
Cc: devicetree-disc...@lists.ozlabs.org; Haojian Zhuang; Ujfalusi, Peter;
linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Quadros, Roger
Subject: [PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use
pinctrl-single-omap
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3.dtsi |4 ++--
arch/arm/boot/dts/omap4.dtsi |4 ++--
arch/arm/boot/dts/omap5.dtsi |4 ++--
arch/arm/mach-omap2/mux.c|8 ++--
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/mach-omap2/prm_common.c | 26 ++
6 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99ba6e1..847af56 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -94,7 +94,7 @@
};
omap3_pmx_core: pinmux@48002030 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002030 0x05cc;
#address-cells = 1;
#size-cells = 0;
@@ -103,7 +103,7 @@
};
omap3_pmx_wkup: pinmux@0x48002a00 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002a00 0x5c;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..2a4f099 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -107,7 +107,7 @@
};
omap4_pmx_core: pinmux@4a100040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a100040 0x0196;
#address-cells = 1;
#size-cells = 0;
@@ -115,7 +115,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap4_pmx_wkup: pinmux@4a31e040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a31e040 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3dd7ff8..5515d58 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -100,7 +100,7 @@
};
omap5_pmx_core: pinmux@4a002840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a002840 0x01b6;
#address-cells = 1;
#size-cells = 0;
@@ -108,7 +108,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap5_pmx_wkup: pinmux@4ae0c840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4ae0c840 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index f82cf87..48094b58 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -811,6 +811,12 @@ int __init omap_mux_late_init(void)
}
}
+ omap_mux_dbg_init();
+
+ /* see pinctrl-single-omap for the wake-up interrupt handling */
+ if (of_have_populated_dt())
+ return 0;
+
ret = request_irq(omap_prcm_event_to_irq(io),
omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
hwmod_io,
Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
Hi Paul, On Monday 10 June 2013 02:05 PM, Lokesh Vutla wrote: Hi Kevin, On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath hvaib...@ti.com AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I have tested BeagleBone boot with today's mainline bootloader and kernel. It boots perfectly fine. I have taken the boot log for BeagleBone from the folllowing site: http://www.pwsan.com/omap/testlogs/test_v3.10-rc5/20130609031534/boot/am335xbone/ I have reset to your U-Boot commit id and took latest mainline kernel. It boots fine in my setup. You can find the logs here: http://pastebin.com/ggVYs3RG Thanks and regards, Lokesh Thanks and regards, Lokesh I've also not been able to boot a mainline kernel on the BeagleBone for some time. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP v3.10-rc regressions that no one's fixed
Hi Paul,
On Monday 10 June 2013 12:52 PM, Paul Walmsley wrote:
Hi folks -- particularly TIers working on mainline,
There are several regressions that started with v3.10-rc that no one's
fixed for over a month. Some of them should be quite easy:
* 37xx EVM: boot fails
- as of v3.10-rc1
- Cause unknown
* 2420N800, 2430sdp: failed to get counter_32k resource
- omap2_sync32k_clocksource_init: failed to get counter_32k resource
- Cause unknown
* 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup
failure
- Cause unknown
- These IP blocks don't exist on OMAP3xxx/AM35xx chips
* 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure
Just booted up my BeagleBone. I didn't see any error for uart4_rx in my
boot log.
Since I don't have other boards, I wanted to reproduce this on my
BeagelBone.
Please let me know if I am missing something.
Thanks and regards,
Lokesh
- Cause unknown
(For more details, see the logs at the link below.)
It would be good if people could step up to fix these before v3.10 comes
out.
- Paul
-- Forwarded message --
Date: Mon, 10 Jun 2013 02:00:50 + (UTC)
From: Paul Walmsley p...@pwsan.com
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Subject: OMAP baseline test results for v3.10-rc5
Here are some basic OMAP test results for Linux v3.10-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc5/20130609031534/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a,
omap1_defconfig, omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only, omap2plus_defconfig,
omap2plus_defconfig_2430sdp_only
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig,
rmk_omap4430_sdp_oldconfig
Build: zImage:
Pass ( 1/ 1): omap2plus_defconfig
Boot to userspace:
FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
Pass ( 9/12): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 4430es2panda, 4460pandaes, 5912osk,
cmt3517
PM: chip retention via suspend:
FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda
Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes
PM: chip retention via dynamic idle:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM: chip off except CORE via suspend:
Pass ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle:
Pass ( 1/ 1): 3730beaglexm
PM: chip off via suspend:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
PM: chip off via dynamic idle:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
Failing tests: fixed by posted patches
--
(none)
Failing tests: needing investigation
Boot tests:
* 3517EVM CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
- Not currently part of the automated test suite
* 37xx EVM: boot fails
- as of v3.10-rc1
- Cause unknown
Boot warnings:
* 2420N800, 2430sdp: failed to get counter_32k resource
- omap2_sync32k_clocksource_init: failed to get counter_32k resource
- Cause unknown
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2
- Longstanding issue; does not occur on the 3517EVM
* 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup
failure
- Cause unknown
- These IP blocks don't exist on OMAP3xxx/AM35xx chips
* 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure
- Cause unknown
PM tests:
* 2430sdp: power domains not entering retention
- Cause unknown
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate (debug ignore_loglevel)
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
* 4430es2panda: pwrdm state mismatch on CAM, DSS
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
- http://marc.info/?l=linux-arm-kernelm=136432340618226w=2
* 4430es2panda: MPU, ABE didn't enter target state
-
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
* Tomi Valkeinen tomi.valkei...@iki.fi [130610 03:44]: On 07/06/13 20:50, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. What issue do you refer to? DSS does not have DT bindings, and removing DSS from hwmod data will break DSS for omap4. Ah that's right. Care to post a patch reverting the minimal parts that you need for omap4 against omap-for-v3.11/cleanup? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
* Quadros, Roger rog...@ti.com [130610 05:37]: Hi Tony, (sorry, on Outlook web) - compatible = ti,omap4-padconf, pinctrl-single; + compatible = ti,omap4-padconf; This change is not necessary if we make sure the pinctrl-single-omap driver gets registered early enough, before the pinctrl devices are probed. (e.g. subsys_initcall()) I'd rather make everything just module_init, there should not be any need to tinker with the init call ordering any longer with deferred probe. And by making everything into regular device drivers we actually see real error messages without DEBUG_LL and earlyprintk if something goes wrong. Note that there are patches queued to make twl-core.c just regular module_init as well, so that should fix any issues you might be related it probing before pinctrl. I've commented about this in the other patch. Sorry can you clarify, which other patch? The other message I saw in this thread was empty. Or at least I have not seen it yet. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c issue on Panda with DT boot, v3.10-rc4
* Tomi Valkeinen tomi.valkei...@iki.fi [130610 02:35]: On 07/06/13 21:36, Tony Lindgren wrote: Maybe check that the i2c related pins are muxed properly for your board with pinctrl-single? Reading the bytes individually with i2cget works fine, so I think that tells us that the pins are configured ok. Yes OK. Maybe there's some i2c driver errata that's not getting configured with the DT based boot? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] serial: omap: Fix device tree based PM runtime
In the runtime_suspend function pdata is not being used, and
also blocks the function in device tree based booting. Fix it
by removing the unused pdata from the runtime_suspend function.
Further, context loss count is not being passed in pdata, so
let's just reinitialize the port every time for those case.
This can be further optimized later on for the device tree
case by adding detection for the hardware state and possibly
by adding a driver specific autosuspend timeout.
And doing this, we can then make the related dev_err into a
dev_dbg message instead of an error.
In order for the wake-up events to work, we also need to set
autosuspend_timeout to -1 if 0, and also device_init_wakeup()
as that's not being done by the platform init code for the
device tree case.
Note that this does not affect legacy booting, and in fact
might make it work for the cases where the context loss info
is not being passed in pdata.
Thanks to Kevin Hilman khil...@linaro.org for debugging
and suggesting fixes for the autosuspend_timeout and
device_init_wakeup() related initializiation.
Reviewed-by: Kevin Hilman khil...@linaro.org
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
Here's this one updated against Linux next.
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -198,7 +198,7 @@ static int serial_omap_get_context_loss_count(struct
uart_omap_port *up)
struct omap_uart_port_info *pdata = up-dev-platform_data;
if (!pdata || !pdata-get_context_loss_count)
- return 0;
+ return -EINVAL;
return pdata-get_context_loss_count(up-dev);
}
@@ -1502,6 +1502,9 @@ static int serial_omap_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, up);
pm_runtime_enable(pdev-dev);
+ if (omap_up_info-autosuspend_timeout == 0)
+ omap_up_info-autosuspend_timeout = -1;
+ device_init_wakeup(up-dev, true);
pm_runtime_use_autosuspend(pdev-dev);
pm_runtime_set_autosuspend_delay(pdev-dev,
omap_up_info-autosuspend_timeout);
@@ -1611,7 +1614,6 @@ static void serial_omap_restore_context(struct
uart_omap_port *up)
static int serial_omap_runtime_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
- struct omap_uart_port_info *pdata = dev-platform_data;
if (!up)
return -EINVAL;
@@ -1626,9 +1628,6 @@ static int serial_omap_runtime_suspend(struct device *dev)
uart_console(up-port))
return -EBUSY;
- if (!pdata)
- return 0;
-
up-context_loss_cnt = serial_omap_get_context_loss_count(up);
if (device_may_wakeup(dev)) {
@@ -1656,7 +1655,7 @@ static int serial_omap_runtime_resume(struct device *dev)
int loss_cnt = serial_omap_get_context_loss_count(up);
if (loss_cnt 0) {
- dev_err(dev, serial_omap_get_context_loss_count failed : %d\n,
+ dev_dbg(dev, serial_omap_get_context_loss_count failed : %d\n,
loss_cnt);
serial_omap_restore_context(up);
} else if (up-context_loss_cnt != loss_cnt) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
* Quadros, Roger rog...@ti.com [130610 03:09]:
+
+static int __init pcs_omap_init(void)
+{
+ platform_driver_register(pcs_omap_soc_driver);
+ platform_driver_register(pcs_omap_driver);
+
+ return 0;
+}
+module_init(pcs_omap_init);
It seems this has to be moved to an earlier place (e.g. subsys_initcall)
else the pinctrl core fails to find the pinctrl device at the device creation
time and bails out with -EPROBE_DEFER. Also, that device is never
created again, so -EPROBE_DEFER doesn't seem to work there.
Ah here, found your other comment :)
That's not needed, the real fix is to make twl-core.c and friends to
be regular module_init. There are already patches queued for that.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
* Tony Lindgren t...@atomide.com [130607 13:58]:
* Tony Lindgren t...@atomide.com [130607 13:56]:
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
This patch I should queue separately, the rest should go via
the pinctrl tree.
Here's this one updated to add stubs for the SoC specific
reconfigure_io_chain functions when the SoC is not selected.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Fri, 7 Jun 2013 11:39:58 -0700
Subject: [PATCH] ARM: OMAP: Move DT wake-up event handling over to use
pinctrl-single-omap
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99ba6e1..847af56 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -94,7 +94,7 @@
};
omap3_pmx_core: pinmux@48002030 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002030 0x05cc;
#address-cells = 1;
#size-cells = 0;
@@ -103,7 +103,7 @@
};
omap3_pmx_wkup: pinmux@0x48002a00 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002a00 0x5c;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..2a4f099 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -107,7 +107,7 @@
};
omap4_pmx_core: pinmux@4a100040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a100040 0x0196;
#address-cells = 1;
#size-cells = 0;
@@ -115,7 +115,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap4_pmx_wkup: pinmux@4a31e040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a31e040 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3dd7ff8..5515d58 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -100,7 +100,7 @@
};
omap5_pmx_core: pinmux@4a002840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a002840 0x01b6;
#address-cells = 1;
#size-cells = 0;
@@ -108,7 +108,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap5_pmx_wkup: pinmux@4ae0c840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4ae0c840 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index f82cf87..48094b58 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -811,6 +811,12 @@ int __init omap_mux_late_init(void)
}
}
+ omap_mux_dbg_init();
+
+ /* see pinctrl-single-omap for the wake-up interrupt handling */
+ if (of_have_populated_dt())
+ return 0;
+
ret = request_irq(omap_prcm_event_to_irq(io),
omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
hwmod_io, omap_mux_late_init);
@@ -818,8 +824,6 @@ int __init omap_mux_late_init(void)
if (ret)
pr_warning(mux: Failed to setup hwmod io irq %d\n, ret);
- omap_mux_dbg_init();
-
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c018593..9b19b14 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -172,6 +172,8 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs, u32
ignore_bits)
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = ~ignore_bits;
c++;
+ if (c 10)
Re: [PATCH 2/4] pinctrl: single: Add hardware specific hooks for IRQ and GPIO wake-up events
* Haojian Zhuang haojian.zhu...@gmail.com [130608 21:51]:
I assume that this patch is used in both v1 v2 version. Since Manjunathappa
changed the logic of distinguishing bits and pins in blew.
if (pcs-bits_per_mux)
mask = vals-mask;
else
mask = pcs-fmask
Would you like to sync with his style?
Thanks for catching that, yes that's how it should be now. Updated
patch below.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Sat, 8 Jun 2013 08:40:35 -0700
Subject: [PATCH] pinctrl: single: Add hardware specific hooks for IRQ and GPIO
wake-up events
At least on omaps, each board typically has at least one device
configured as wake-up capable from deeper idle modes. In the
deeper idle modes the normal interrupt wake-up path won't work
as the logic is powered off and separate wake-up hardware is
available either via IO ring or GPIO hardware. The wake-up
event can be device specific, or may need to be dynamically
remuxed to GPIO input for wake-up events. When the wake-up
event happens, it's IRQ need to be called so the device won't
lose interrupts.
Allow supporting IRQ and GPIO wake-up events if a hardware
spefific module is registered for the enable and disable
calls.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5a02e30..b95fa6c 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -69,6 +69,10 @@ Optional properties:
The number of parameters is depend on #pinctrl-single,gpio-range-cells
property.
+- interrrupts : the interrupt that a function may have for a wake-up event
+
+- gpios: the gpio that a function may have for a wake-up event
+
/* pin base, nr pins gpio function */
pinctrl-single,gpio-range = range 0 3 0 range 3 9 1;
@@ -205,6 +209,7 @@ pmx_gpio: pinmux@d401e000 {
0xdc 0x118
0xde 0
;
+ interrupts = 74;
};
};
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index e3b1f76..72efc8e 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -19,6 +19,8 @@
#include linux/of.h
#include linux/of_device.h
#include linux/of_address.h
+#include linux/of_gpio.h
+#include linux/of_irq.h
#include linux/pinctrl/pinctrl.h
#include linux/pinctrl/pinmux.h
@@ -95,6 +97,8 @@ struct pcs_conf_type {
* @nvals: number of entries in vals array
* @pgnames: array of pingroup names the function uses
* @npgnames: number of pingroup names the function uses
+ * @irq: optional irq associated with the function
+ * @gpio: optional gpio associated with the function
* @node: list node
*/
struct pcs_function {
@@ -105,6 +109,8 @@ struct pcs_function {
int npgnames;
struct pcs_conf_vals *conf;
int nconfs;
+ int irq;
+ int gpio;
struct list_head node;
};
@@ -411,6 +417,18 @@ static int pcs_get_function(struct pinctrl_dev *pctldev,
unsigned pin,
return 0;
}
+static void pcs_reg_init(struct pcs_reg *p, struct pcs_device *pcs,
+struct pcs_function *func,
+void __iomem *reg, unsigned val)
+{
+ p-read = pcs-read;
+ p-write = pcs-write;
+ p-irq = func-irq;
+ p-gpio = func-gpio;
+ p-reg = reg;
+ p-val = val;
+}
+
static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector,
unsigned group)
{
@@ -444,6 +462,12 @@ static int pcs_enable(struct pinctrl_dev *pctldev,
unsigned fselector,
val = ~mask;
val |= (vals-val mask);
pcs-write(val, vals-reg);
+ if ((func-irq || func-gpio) pcs-soc pcs-soc-enable) {
+ struct pcs_reg pcsr;
+
+ pcs_reg_init(pcsr, pcs, func, vals-reg, val);
+ pcs-soc-enable(pcs-soc, pcsr);
+ }
}
return 0;
@@ -468,18 +492,6 @@ static void pcs_disable(struct pinctrl_dev *pctldev,
unsigned fselector,
return;
}
- /*
-* Ignore disable if function-off is not specified. Some hardware
-* does not have clearly defined disable function. For pin specific
-* off modes, you can use alternate named states as described in
-* pinctrl-bindings.txt.
-*/
- if (pcs-foff == PCS_OFF_DISABLED) {
- dev_dbg(pcs-dev, ignoring disable for %s function%i\n,
- func-name, fselector);
- return;
-
Re: [net-next PATCH v4 1/5] net: cpsw: enhance pinctrl support
On Fri, Jun 7, 2013 at 4:49 PM, Mugunthan V N mugunthan...@ti.com wrote: If you want to merge the direct networking parts of this series into another tree, I'm fine with that: Acked-by: David S. Miller da...@davemloft.net David Can you the below patch series as i have adopted pinctrl PM api in another series, this patch has direct usage of pinctrl_select_state apis http://marc.info/?l=linux-netdevm=137054250018667w=2 Linus Walleij Please drop this patch series and take my other [atch set mentioned above with David's Ack. Sure I didn't see David ACK the new versions explicitly but since they're even less intrusive I'll apply them assuming his ACK on these versions too... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] drivers: net: cpsw: use pinctrl PM helpers
On Thu, Jun 6, 2013 at 8:15 PM, Mugunthan V N mugunthan...@ti.com wrote: This utilize the new pinctrl core PM helpers to transition the driver to default and sleep states. Signed-off-by: Mugunthan V N mugunthan...@ti.com This version of the patch applied with DaveM:s ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drivers: net: davinci_mdio: use pinctrl PM helpers
On Thu, Jun 6, 2013 at 8:15 PM, Mugunthan V N mugunthan...@ti.com wrote: This utilize the new pinctrl core PM helpers to transition the driver to default and sleep states. Signed-off-by: Mugunthan V N mugunthan...@ti.com This version of the patch applied with DaveM:s ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime
On Fri, Jun 7, 2013 at 11:49 PM, Tony Lindgren t...@atomide.com wrote:
On some omaps we need to remux MMC pins for PM, and for some omaps
we need to remux the SDIO IRQ pin.
Based on an earlier patch by Andreas Fenkart afenk...@gmail.com.
(...)
+ host-pinctrl = devm_pinctrl_get(host-dev);
+ if (IS_ERR(host-pinctrl)) {
+ dev_dbg(host-dev, no pinctrl handle\n);
+ ret = 0;
+ goto out;
+ }
+
+ host-fixed = pinctrl_lookup_state(host-pinctrl,
+ PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(host-fixed)) {
+ dev_dbg(host-dev,
+pins are not configured from the driver\n);
+ host-fixed = NULL;
+ ret = 0;
+ goto out;
+ }
+
+ ret = pinctrl_select_state(host-pinctrl, host-fixed);
+ if (ret 0)
+ goto err;
+
+ /* For most cases we don't have wake-ups, and exit after this */
+ host-active = pinctrl_lookup_state(host-pinctrl, active);
+ if (IS_ERR(host-active)) {
+ ret = PTR_ERR(host-active);
+ host-active = NULL;
+ return 0;
+ }
+
+ host-idle = pinctrl_lookup_state(host-pinctrl,
+ PINCTRL_STATE_IDLE);
+ if (IS_ERR(host-idle)) {
+ ret = PTR_ERR(host-idle);
+ host-idle = NULL;
+ goto err;
+ }
You can use the new infrastructure to make the core select:
pinctrl_pm_select_default_state(host-dev);
pinctrl_pm_select_idle_state(host-dev);
What is the semantic difference between default and active?
If this is something very generic that a lot of platforms will want
to have, why not add it to include/linux/pinctrl/pinctrl-state.h
and augment the core to cache and handle this too?
However in this case I *suspect* that what you really want
to do it to rename the state called default to sleep
(it appears the default state is sleepy) and then rename
the active state to default (as this is the defined semantic
meaning of default from linux/pinctrl/pinctrl-state.h.
But maybe I'm not quite getting the subtle difference between
default and active here so enlighten me.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
+Paul. On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown broo...@kernel.org wrote: On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. Patch #4 in this series was a hack as it was not properly split up and organized as a proper DTS series -it was meant as a proof of concept - not entirely meant to indicate the remaining 1-3 patches were hacks :). +- ti,i2c-slave-address - I2C slave address of the PMIC +- ti,i2c-voltage-register - I2C register address where voltage commands are + to be set. +- ti,i2c-command-register - I2C register address where commands are to be set + when OMAP enters low power state. This may be the same as + ti,i2c-voltage-register depending on the PMIC. +- ti,slew-rate-microvolt - worst case slew rate of rise / fall for voltage + transition in microvolts per microseconds (uV/uS) +- step-size-micro-volts - Step size in micovolts as to what one step in voltage + selector increment translates to. See example. +- regulator-min-microvolt - Minimum voltage in microvolts which is supported by + the PMIC in ti,step-size-microvolt increments. See example. +- regulator-max-microvolt - Maximum voltage in microvolts which is supported + by the PMIC in ti,step-size-microvolt increments. See example. The other thing is this whole business of encoding the properties of the PMIC in the DT like this. Paul Walmsley has started doing some work for some similiar hardware where instead of doing this the regulator is in the DT as normal and then the driver for the offloaded voltage scaling gets the information about the register layout from the regulator driver. This is a bit neater overall and would cope with determining which method to use at runtime. I think you mean http://marc.info/?t=13705924913r=1w=2 series. I will dig into it. if it is possible for Tegra and OMAP to use the same framework and strategy to deal with these kind of h/w blocks, all the more better. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/10/2013 03:29 AM, Benoit Cousson wrote:
Hi Keerthy,
On 06/10/2013 06:03 AM, J, KEERTHY wrote:
Hi Stephen,
Thanks for the review comments.
From: Stephen Warren [swar...@wwwdotorg.org]
Sent: Saturday, June 08, 2013 1:26 AM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org;
linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/07/2013 05:28 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
+palmas {
Hmmm. That (i.e. requiring the board file to declare the node, then
setting up all the content by later including this file) is an
interesting approach. I guess it's reasonable. The one issue is that it
makes it a little harder for the board file to override any of the
properties in this file., although it certainly is possible by including
those overrides after the include.
Irrespective of that, some comments on this:
+ palmas_pmic {
+ ti,ldo6-vibrator;
For example, what if the board doesn't want to have the property set?
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
Or what if the board wants to limit the voltage range of this regulator
due to what it's used for on the board.
+ regulator-always-on;
+ regulator-boot-on;
And those two properties are almost certainly board-specific policy.
Totally agree to all the above concerns. So can we have a custom .dtsi file
for a board+pmic combination? Or have only the required properties over
ridden
in the board file?
Yes, you can do that potentially if most OMAP5 boards will reuse the
same kind of settings. Kevin has just done that for OMAP3 + twl4030.
In this case, since we do have only one board, I'm not sure it worth the
effort.
IIUC, various Tegra boards use this PMIC, so there's more than one board
in question here.
Or were you talking about e.g.:
palmas.dtsi - base Palmas DT node for everything
omap-palmas.dtsi - common Palmas settings for all OMAP boards
... where the latter file would only be used by one board? If so, then
yes, creating the latter file might not make sense yet.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/09/2013 10:03 PM, J, KEERTHY wrote: Hi Stephen, Thanks for the review comments. Cam you please fix your email client to quote the messages you're replyiing to correctly? In the message you sent, there's no differentiation between what I originally wrote and you quoted, vs. the new text you wrote as a response. That makes the message very confusing to read... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: dts: add dtsi for palmas
On 06/10/2013 03:04 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes.
Nits:
Well, you're really adding files that provide the nodes, not the nodes
themselves.
Palmas and MFD should be correctly capitalized.
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
+palmas {
...
+ palmas_pmic {
...
+ ti,ldo6-vibrator;
Isn't that board-specific? I don't know the HW well enough to say, but I
assume that since there's a property, the whole point must be that some
boards want it set and some don't.
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ };
So the node labels here duplicate those in omap5-uevm.dts in patch 2/2.
While dtc allows this, I don't think there's much point duplicating the
labels. I'd tend to only put the labels in omap5-uevm.dts and not put
them here. That will completely avoid the possibility of the labels in
this file from conflicting with any other labels in any top-level
board.dts file.
I also wonder if this file is actually terribly useful. The only thing
that this file provides is the regulator-name property. It seems simpler
just to put that into each board.dts file. The added advantage of doing
that, is that if a board doesn't use a particular regulator, the node
won't appear, and the regulator won't get registered.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
Benoit Cousson b-cous...@ti.com writes: Hi Kevin, On 06/07/2013 09:31 PM, Nishanth Menon wrote: On 11:31-20130607, Kevin Hilman wrote: On most OMAP3 platforms, the twl4030 IRQ line is connected to the SYS_NIRQ line on OMAP. Add another DTS include file (twl4030_omap3.dtsi) for boards that hook up the twl4030 this way to include. This allows RTC wake from off-mode to work again on OMAP3-based platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM, 3530/Overo, 3730/Overo-STORM. Special thanks to Florian Vaussard for suggesting use of preprocessor feature. Cc: Florian Vaussard florian.vauss...@epfl.ch Cc: Benoit Cousson b-cous...@ti.com Cc: Nishanth Menon n...@ti.com Signed-off-by: Kevin Hilman khil...@linaro.org Thanks, Reviewed-by: Nishanth Menon n...@ti.com Thanks, I've just applied it in for_3.11/dts. Thanks, Will you apply the first 2 from the series too? ARM: DTS: OMAP3: beagle/overo: mux console UART, enable wakeup ARM: DTS: OMAP3: beagle: enable user button via gpio_keys, enable wakeup Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime
* Linus Walleij linus.wall...@linaro.org [130610 09:09]: You can use the new infrastructure to make the core select: pinctrl_pm_select_default_state(host-dev); pinctrl_pm_select_idle_state(host-dev); OK great. What is the semantic difference between default and active? We only should remux the pins that need remuxing as that's done every time hitting idle. So I think we should have the following default groups: default Static pins that don't change, no need to remux configured in consumer driver probe like we already do active Optional dynamic pins remuxed for runtime, can be configured and selected in consumer driver probe. The consumer driver may also want to select this state in PM runtime resume. idleOptional dynamic pins remuxed for idle. The consumer driver may also want to select this state in PM runtime suspend depending on device_can_wakeup() and driver specific needs. If this is something very generic that a lot of platforms will want to have, why not add it to include/linux/pinctrl/pinctrl-state.h and augment the core to cache and handle this too? Yes we should do that assuming the above grouping makes sense to you. However in this case I *suspect* that what you really want to do it to rename the state called default to sleep (it appears the default state is sleepy) and then rename the active state to default (as this is the defined semantic meaning of default from linux/pinctrl/pinctrl-state.h. The idle state above could also be called sleep instead of idle if you prefer that. But maybe I'm not quite getting the subtle difference between default and active here so enlighten me. I think the confusion is caused by the fact that we need three mux groups, not just two :) The toggling between active and idle is the hotpath as that can potentially happen for multiple drivers every time we enter and exit idle. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 11:16:59AM -0500, Nishanth Menon wrote: On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown broo...@kernel.org wrote: On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. Patch #4 in this series was a hack as it was not properly split up and organized as a proper DTS series -it was meant as a proof of concept - not entirely meant to indicate the remaining 1-3 patches were hacks :). The way it reads is that you're building up to a hack - if what you've done isn't enabling a sensible solution there might be a problem with the earlier steps. I think you mean http://marc.info/?t=13705924913r=1w=2 series. I will dig into it. if it is possible for Tegra and OMAP to use the same framework and strategy to deal with these kind of h/w blocks, all the more better. Not just better, if each system doing this sort of thing needs to reinvent the wheel something is going wrong. signature.asc Description: Digital signature
Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
Hi Lokesh, Lokesh Vutla lokeshvu...@ti.com writes: Hi Kevin, On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath hvaib...@ti.com AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I have tested BeagleBone boot with today's mainline bootloader and kernel. It boots perfectly fine. Can you post git trees + branch names (and/or commit IDs) and also kernel config please? Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: OMAP2+: mbox: remove dependencies with soc.h
Russ,
On 06/08/2013 02:16 PM, Russ Dill wrote:
On Fri, Jun 7, 2013 at 6:58 PM, Suman Anna s-a...@ti.com wrote:
The OMAP mailbox platform driver code has been cleaned up to
remove the dependencies with soc.h in preparation for moving
the mailbox code to drivers folder.
The code relied on cpu_is_xxx/soc_is_xxx macros previously to
pick the the right set of mailbox devices and register with the
mailbox driver. This data is now represented in a concise format
and moved to the respective omap_hwmod data files and published
to the driver through the platform data.
I have some comments on how the cpu_is_xxx/soc_is_xxx was done. In its
current form, intr_type is just a sub for cpu_is_omap44xx(). I'd like
to see the scope of that parameter reduced a bit and have the changes
match the model of gpio-omap.c a little better (see 4e962e89 for an
example). Comments inline.
I have looked up the gpio-omap.c and the usage style is different. The
purpose here is similar, the interrupt programming is different between
OMAP4+ and OMAP3-. For gpio, all the registers are supplied through
platform data (published differently for DT and non-DT). The knowledge
of the registers is with the driver for mailbox (in both DT and non-DT),
with only the bare minimum data passed through pdata (for non-DT) with
this patch. The only variation in mailbox registers is the interrupt
type configuration, the number of valid registers are dictated by number
of fifos and number of target processors, and I have added these to the
platform data in Patch6. The main purpose of this patch is to remove the
cpu_is_xxx macro dependencies which are currently used for defining the
different mboxes as well as the register programming. I didn't want to
separate out the mailbox device creation into a separate file with all
the additional data that this patch is removing, we do not want to
create a new file in mach-omap2 at this point. The omap_mbox_init will
essentially vanish for DT, and so would be the dev_attrs being added to
the hwmod data files.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/devices.c | 9 +-
arch/arm/mach-omap2/mailbox.c | 250
++---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 12 ++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 11 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 11 ++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 ++
arch/arm/plat-omap/include/plat/mailbox.h | 2 +-
include/linux/platform_data/mailbox-omap.h | 53 ++
8 files changed, 198 insertions(+), 163 deletions(-)
create mode 100644 include/linux/platform_data/mailbox-omap.h
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 4269fc1..4c97a86 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@
#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
#include linux/platform_data/omap_ocp2scp.h
+#include linux/platform_data/mailbox-omap.h
#include linux/usb/omap_control_usb.h
#include asm/mach-types.h
@@ -332,14 +333,20 @@ static inline void __init omap_init_mbox(void)
{
struct omap_hwmod *oh;
struct platform_device *pdev;
+ struct omap_mbox_pdata *pdata;
oh = omap_hwmod_lookup(mailbox);
if (!oh) {
pr_err(%s: unable to find hwmod\n, __func__);
return;
}
+ if (!oh-dev_attr) {
+ pr_err(%s: hwmod doesn't have valid attrs\n, __func__);
+ return;
+ }
- pdev = omap_device_build(omap-mailbox, -1, oh, NULL, 0);
+ pdata = (struct omap_mbox_pdata *)oh-dev_attr;
+ pdev = omap_device_build(omap-mailbox, -1, oh, pdata,
sizeof(*pdata));
WARN(IS_ERR(pdev), %s: could not build device, err %ld\n,
__func__, PTR_ERR(pdev));
}
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index b01aae6..fcb425c 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -11,16 +11,16 @@
*/
#include linux/module.h
+#include linux/slab.h
#include linux/clk.h
#include linux/err.h
#include linux/platform_device.h
#include linux/io.h
#include linux/pm_runtime.h
+#include linux/platform_data/mailbox-omap.h
#include plat/mailbox.h
-#include soc.h
-
#define MAILBOX_REVISION 0x000
#define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
#define MAILBOX_FIFOSTATUS(m) (0x080 + 4 * (m))
@@ -59,6 +59,7 @@ struct omap_mbox2_priv {
u32 notfull_bit;
u32 ctx[OMAP4_MBOX_NR_REGS];
unsigned long irqdisable;
+ u32 intr_type;
};
static inline unsigned int mbox_read_reg(size_t ofs)
@@ -136,7 +137,7 @@ static void omap2_mbox_disable_irq(struct omap_mbox
*mbox, omap_mbox_irq_t irq)
struct
Re: [PATCH 2/7] omap: mailbox: check for NULL nb in mailbox_put
Russ,
On 06/08/2013 01:46 PM, Russ Dill wrote:
On Fri, Jun 7, 2013 at 6:57 PM, Suman Anna s-a...@ti.com wrote:
The mailbox_put function must check the notifier block for
NULL before trying to unregister it.
I'm going to nack this one. Why must it check for NULL? None of the
callers pass a NULL argument and blocking_notifier_chain_unregister
handles a NULL nb argument just fine.
Thanks for the review. It should have been done differently, which is to
print an error trace if the passed in arguments are NULL. Anyway, I will
drop this since I expect this function to go away once this is adapted
to the new framework.
regards
Suman
Signed-off-by: Fernando Guzman Lugo lugo.ferna...@gmail.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/plat-omap/mailbox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 42377ef..5fb4027 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -356,7 +356,8 @@ EXPORT_SYMBOL(omap_mbox_get);
void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb)
{
- blocking_notifier_chain_unregister(mbox-notifier, nb);
+ if (nb)
+ blocking_notifier_chain_unregister(mbox-notifier, nb);
omap_mbox_fini(mbox);
}
EXPORT_SYMBOL(omap_mbox_put);
--
1.8.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/3] PM / AVS: SmartReflex: use omap_sr * for class interfaces
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes: SmartReflex driver interface is natively divided to two parts: - external SmartReflex interface - interface between SmartReflex driver and SmartReflex Class Functions which belong to AVS class interface can use struct omap_sr* instead of struct voltatedomain*, to provide a direct connection between SR driver and SR class. This allows us to optimize and not do additional lookups where none is required. Patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git tag: v3.10-rc2 Verified on OMAP4430. Boot - OK. SmartReflex registers debug dump - OK Available on GitHub: https://github.com/andriit/linux-omap-k3.8/commits/avs_sr_driver_std_class_interfaces_v01 Andrii Tseglytskyi (3): PM / AVS: SmartReflex: use omap_sr * for errgen interfaces PM / AVS: SmartReflex: use omap_sr * for minmax interfaces PM / AVS: SmartReflex: use omap_sr * for enable/disable interface arch/arm/mach-omap2/smartreflex-class3.c |8 ++-- drivers/power/avs/smartreflex.c | 63 +++--- include/linux/power/smartreflex.h| 10 ++--- 3 files changed, 40 insertions(+), 41 deletions(-) Thanks, queuing this series for v3.11. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] PM / AVS: SmartReflex: use devm_* API to initialize SmartReflex
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes: Use of of devm_* API for resource allocation provides benefits such as auto handling of resource free. This reduces possibility have memory leaks in case of wrong error handling. All direct release calls should be removed to avoid races. Reported-by: Grygorii Strashko grygorii.stras...@ti.com Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@ti.com Thanks, queuing this for v3.11. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 11:49 AM, Mark Brown broo...@kernel.org wrote: On Mon, Jun 10, 2013 at 11:16:59AM -0500, Nishanth Menon wrote: On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown broo...@kernel.org wrote: On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. Patch #4 in this series was a hack as it was not properly split up and organized as a proper DTS series -it was meant as a proof of concept - not entirely meant to indicate the remaining 1-3 patches were hacks :). The way it reads is that you're building up to a hack - if what you've done isn't enabling a sensible solution there might be a problem with the earlier steps. Understood, I should have taken extra steps to split up the patch into it's logical series, but wanted to get a quick feel from community about the approach before spending time on it. I apologize for the confusion caused. I think you mean http://marc.info/?t=13705924913r=1w=2 series. I will dig into it. if it is possible for Tegra and OMAP to use the same framework and strategy to deal with these kind of h/w blocks, all the more better. Not just better, if each system doing this sort of thing needs to reinvent the wheel something is going wrong. Fair enough, I did spend a short while digging through the discussion in the series, I need to find Tegra TRM to see if there is commonolity between OMAP and what Tegra does at hardware level. a) Tegra seems to use Lookup Table for sending predefinied voltage values to PMIC. OMAP has no concept of lookup table. b) Tegra and OMAP h/w blocks seem to use I2C - that is good. c) How about the i2c slave and register addresses, slew rates, start, end voltages, max voltages that SoC can support etc, I am yet to understand those. d) OMAP has 3 modules - AVS (SmartReflex), Voltage Processor(VP), Voltage Controller(VC) - I am not yet sure about the Tegra hardware blocks involved. maybe Paul could comment as well, I suppose if we could take a common approach between Tegra and OMAP. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] PM / AVS: SmartReflex/class3: Fix order of initialization of SR class and SR driver
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes:
SmartReflex consists of three entities: SR device, SR class and
SR driver. SmartReflex driver depends on SmartReflex class, but
order of their initialization is not clear. They both use
late_initcall(), and order depends on Makefile calls.
Patch moves initialization of SR class to device_initcall(),
and removes redundant call of sr_late_init().
This provides predictable order of SmartReflex initcalls:
1. device_initcall() - SmartReflex class init
2. late_initcall() - SmartReflex driver init
Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@ti.com
Tony will have to decide on whether he's OK with the initcall changes.
I can queue this with the rest of the AVS changes with Tony's ack.
Kevin
---
arch/arm/mach-omap2/smartreflex-class3.c |2 +-
drivers/power/avs/smartreflex.c |9 -
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index aee3c89..50523b8 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -59,4 +59,4 @@ static int __init sr_class3_init(void)
pr_info(SmartReflex Class3 initialized\n);
return sr_register_class(class3_data);
}
-omap_late_initcall(sr_class3_init);
+omap_device_initcall(sr_class3_init);
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index fd71d5a..42eed34 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -650,8 +650,6 @@ void sr_disable(struct voltagedomain *voltdm)
*/
int sr_register_class(struct omap_sr_class_data *class_data)
{
- struct omap_sr *sr_info;
-
if (!class_data) {
pr_warning(%s:, Smartreflex class data passed is NULL\n,
__func__);
@@ -666,13 +664,6 @@ int sr_register_class(struct omap_sr_class_data
*class_data)
sr_class = class_data;
- /*
- * Call into late init to do intializations that require
- * both sr driver and sr class driver to be initiallized.
- */
- list_for_each_entry(sr_info, sr_list, node)
- sr_late_init(sr_info);
-
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 12:51:42PM -0500, Nishanth Menon wrote: a) Tegra seems to use Lookup Table for sending predefinied voltage values to PMIC. OMAP has no concept of lookup table. They seem to be doing basically the same thing here, you've got a linear map of selector to voltage too AFAICT. b) Tegra and OMAP h/w blocks seem to use I2C - that is good. c) How about the i2c slave and register addresses, slew rates, start, end voltages, max voltages that SoC can support etc, I am yet to understand those. d) OMAP has 3 modules - AVS (SmartReflex), Voltage Processor(VP), Voltage Controller(VC) - I am not yet sure about the Tegra hardware blocks involved. This all seems like it's at the implementation detail level - the bit that seems like we should be able to share it is the big picture bit for how we describe how the AP side stuff and PMIC are hooked up without having to have a bunch of completely non-framework stuff for things like describing the PMIC. signature.asc Description: Digital signature
Re: [PATCH 3/7] omap: mailbox: call request_irq after mbox queues are allocated
Russ,
On 06/08/2013 01:53 PM, Russ Dill wrote:
On Fri, Jun 7, 2013 at 6:57 PM, Suman Anna s-a...@ti.com wrote:
The OMAP mailbox startup code is enabling the interrupt even before
any of the associated mailbox queues are allocated. Any pending
received mailbox message could cause a kernel panic as soon as
the interrupt is enabled due to the dereferencing of non-existing
mailbox queues within the ISR.
Signed-off-by: Fernando Guzman Lugo lugo.ferna...@gmail.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/plat-omap/mailbox.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 5fb4027..e1bd333 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -261,13 +261,6 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
}
if (!mbox-use_count++) {
- ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
- mbox-name, mbox);
- if (unlikely(ret)) {
- pr_err(failed to register mailbox interrupt:%d\n,
- ret);
- goto fail_request_irq;
- }
mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
if (!mq) {
ret = -ENOMEM;
@@ -282,17 +275,24 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
}
mbox-rxq = mq;
mq-mbox = mbox;
+ ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
+ mbox-name, mbox);
+ if (unlikely(ret)) {
+ pr_err(failed to register mailbox interrupt:%d\n,
+ ret);
+ goto fail_request_irq;
+ }
omap_mbox_enable_irq(mbox, IRQ_RX);
I can't help but to notice the IRQ unmasking function here. Is there a
reason it isn't working?
This patch was based on an internal patch needed before the equivalent
of 1d8a0e9 ARM: OMAP: enable mailbox irq per instance is merged. I
will revise the patch description - this is more of a minor cleanup now
rather than a fix, would have been a fix without the above patch. Thanks
for pointing it out.
regards
Suman
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/2] ARM: dts: add dtsi for palmas
Hi Stephen,
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Monday, June 10, 2013 9:59 PM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH v2 1/2] ARM: dts: add dtsi for palmas
On 06/10/2013 03:04 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes.
Nits:
Well, you're really adding files that provide the nodes, not the nodes
themselves.
Palmas and MFD should be correctly capitalized.
Ok.
diff --git a/arch/arm/boot/dts/palmas.dtsi
b/arch/arm/boot/dts/palmas.dtsi
+palmas {
...
+ palmas_pmic {
...
+ ti,ldo6-vibrator;
Isn't that board-specific? I don't know the HW well enough to say, but
I assume that since there's a property, the whole point must be that
some boards want it set and some don't.
Yes. I will make this part of board file.
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ };
So the node labels here duplicate those in omap5-uevm.dts in patch 2/2.
While dtc allows this, I don't think there's much point duplicating the
labels. I'd tend to only put the labels in omap5-uevm.dts and not put
them here. That will completely avoid the possibility of the labels in
this file from conflicting with any other labels in any top-level
board.dts file.
I also wonder if this file is actually terribly useful. The only thing
that this file provides is the regulator-name property. It seems
simpler just to put that into each board.dts file. The added advantage
of doing that, is that if a board doesn't use a particular regulator,
the node won't appear, and the regulator won't get registered.
Ok. I will transfer the entire code to omap5-uevm.dts.
Thanks for the review comments.
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
Hi Kevin, On Monday 10 June 2013 10:33 PM, Kevin Hilman wrote: Hi Lokesh, Lokesh Vutla lokeshvu...@ti.com writes: Hi Kevin, On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath hvaib...@ti.com AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I have tested BeagleBone boot with today's mainline bootloader and kernel. It boots perfectly fine. Can you post git trees + branch names (and/or commit IDs) and also kernel config please? Following are the details: U-Boot: url:git://git.denx.de/u-boot.git branch :master config: am335x_evm Top commit: 842033e pci: introduce CONFIG_PCI_INDIRECT_BRIDGE option Kernel: url: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git branch: master config: omap2plus_defocnfig dtb file: am335x-bone.dtb Top commit: 317ddd2 Linux 3.10-rc5 (On top of this I have a local patch for appending dtb) You can find the logs here: http://pastebin.com/vcBr0UhM Thanks and regards, Lokesh Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: dts: OMAP5: Add palmas MFD node and regulator nodes
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 170 ++
1 files changed, 170 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..6fbe47c 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,174 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ };
+};
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = ldo2;
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-name = ldo3;
+ regulator-min-microvolt = 300;
+
