Display not working if omapdrm is builtin with 3.15rc
Hi, I've been trying to get DVI on my beagleboard XM to output a picture with mainline and with 3.15rc it still doesn't work. If I statically build in everything the drm encoders and connectors all go into deferred probe mode and fail, falling back to 1024x768. I with omapdrm and encoders/outputs/etc as modules deferred probe is avoided, far fewer error messages and a 1280x1024 resolution is being used. But still the monitor still says 'no signal' detected. So what's the magic to get an actual signal on the hdmi connector? regards, Koen-- 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: Display not working if omapdrm is builtin with 3.15rc
Op 2 mei 2014, om 13:25 heeft Javier Martinez Canillas jav...@dowhile0.org het volgende geschreven: Hello Koen, On Fri, May 2, 2014 at 12:47 PM, Koen Kooi k...@dominion.thruhere.net wrote: Hi, I've been trying to get DVI on my beagleboard XM to output a picture with mainline and with 3.15rc it still doesn't work. If I statically build in everything the drm encoders and connectors all go into deferred probe mode and fail, falling back to 1024x768. I with omapdrm and encoders/outputs/etc as modules deferred probe is avoided, far fewer error messages and a 1280x1024 resolution is being used. But still the monitor still says 'no signal' detected. So what's the magic to get an actual signal on the hdmi connector? regards, Koen-- This is a known issue as far as I know. You need [0] to correctly set the display PLL clock rates. OK, 1/2 is already in and I applied 2/2 manually. Still no picture on screen :( root@beagleboard:~# dmesg | grep -i fb .init : 0xc07a9000 - 0xc07fb040 ( 329 kB) [3.830474] Freeing unused kernel memory: 328K (c07a9000 - c07fb000) [ 10.082489] omapdrm omapdrm.0: fb0: omapdrm frame buffer device root@beagleboard:~# dmesg | grep -i drm [3.042266] [drm] Initialized drm 1.1.0 20060810 [9.785095] omapdrm omapdrm.0: DMM not available, disable DMM support [9.792816] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [9.799865] [drm] No driver support for vblank timestamp query. [ 10.082489] omapdrm omapdrm.0: fb0: omapdrm frame buffer device [ 10.088775] omapdrm omapdrm.0: registered panic notifier [ 10.094421] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0 root@beagleboard:~# dmesg | grep -i dvi [6.943420] connector-dvi connector.10: failed to find video source [6.950256] platform connector.10: Driver connector-dvi requests probe deferral Then I used this uSD card in a different board and I get the orange u-boot screen and later a GNOME desktop. So it seems I tested it with a broken board :/ Nevertheless, everything as builtin is still broken, but with modules it seems to work. regards, Koen-- 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: Display not working if omapdrm is builtin with 3.15rc
Op 2 mei 2014, om 13:59 heeft Tomi Valkeinen tomi.valkei...@ti.com het volgende geschreven: On 02/05/14 13:47, Koen Kooi wrote: Hi, I've been trying to get DVI on my beagleboard XM to output a picture with mainline and with 3.15rc it still doesn't work. If I statically build in everything the drm encoders and connectors all go into deferred probe mode and fail, falling back to 1024x768. I with omapdrm and encoders/outputs/etc as modules deferred probe is avoided, far fewer error messages and a 1280x1024 resolution is being used. But still the monitor still says 'no signal' detected. So what's the magic to get an actual signal on the hdmi connector? Sigh, looks like my beagle xM died on me while testing this... The reason for this is that the twl_gpio (which TFP410 uses) gets initialized really late, so display things get deferred. Then, before TFP410 has initialized, omapdrm starts. It finds VENC (tv-out) display available, so it starts. After that TFP410 gets probed, but as DRM doesn't support adding displays later, it is never actually added to omapdrm. Also, the VENC output doesn't even work by default if CONFIG_DRM_OMAP_NUM_CRTCS is 1. It needs to be set to 2 to support the second output (tv-out in this case). But my board died before I managed to test this. So, the probing is quite broken. And I have no good ideas how to fix it, only bad ones... A simple thing to do for testing is to either disable CONFIG_OMAP2_DSS_VENC from the kernel, or remove the svideo-connector from the board's .dts file. This results in tv-out not being available, so when omapdrm starts and finds no displays, it'll defer its probe, thus getting the DVI next time it probes. I disabled CONFIG_OMAP2_DSS_VENC and DVI works as expected with everything builtin! regards, Koen-- 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 v4 0/2] ARM: dts: Beaglebone MMC fixes
Op 13 sep. 2013, om 00:27 heeft Kevin Hilman khil...@linaro.org het volgende geschreven: Koen Kooi k...@dominion.thruhere.net writes: Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1 gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + 564fc88cc64387af5312e2abd8019c75a13223b2 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + e5133ed98acc1c3e01c370b851041a8ca629cd15 ARM: EDMA: Fix clearing of unused list for DT DMA resources + ac71bb58605d3bdd5d14af770a639fb3ff11c612 ARM: dts: add AM33XX EDMA support + 31a8270a299c57c7de7510f44d9dc36fd1787243 ARM: dts: add AM33XX SPI DMA support + 4fa0a4cb9ea17da30cf43085c03e5ec1361a4fc2 ARM: dts: add AM33XX MMC support and documentation + 0553f50bd45f019a0cc11050e2f20bddbf07dfe0 ARM: dts: am335x-bone: add CD for mmc1 + 7d64f765630a2921a63b82f93f9959a6de37f29d ARM: dts: am335x-boneblack: add eMMC DT entry + dc96cd4003e2668d8ec7e7fe19e402e97a198f81 ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode + f8262e78830cda56c936724549ba9f04e312 ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline FWIW, tested this branch on BB black/white with MMC rootfs. Tested-by: Kevin Hilman khil...@linaro.org Koen, Thanks for your persistence getting this stuff merged. No problem, with all comments addressed I can safely disappear for 3 weeks to go on honeymoon :) regards, Koen-- 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/3] ARM: OMAP2+: BBB DT: mark eMMC as non removable
Op 13 sep. 2013, om 12:09 heeft Sekhar Nori nsek...@ti.com het volgende geschreven: Mark the eMMC module on BeagleBone black as non removable. Signed-off-by: Sekhar Nori nsek...@ti.com Acked-by: Koen Kooi k...@dominion.thruhere.net --- arch/arm/boot/dts/am335x-boneblack.dts |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts index f4703cf..58515dc 100644 --- a/arch/arm/boot/dts/am335x-boneblack.dts +++ b/arch/arm/boot/dts/am335x-boneblack.dts @@ -25,6 +25,7 @@ pinctrl-names = default; pinctrl-0 = emmc_pins; bus-width = 8; + non-removable; status = okay; ti,vcc-aux-disable-is-sleep; }; -- 1.7.10.1 -- 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 1/4] arm: bone: dts: add CD for mmc1
From: Alexander Holler hol...@ahsoftware.de
This enables the use of MMC cards even when no card was inserted at boot.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v2:
None, again a simple repost
Changes since v1:
None, simple repost
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 ++
arch/arm/boot/dts/am335x-bone.dts | 4
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2f66ded..ced256c 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -107,6 +107,11 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
+ ;
+ };
};
ocp {
@@ -260,3 +265,12 @@
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = ldo3_reg;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+ cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
+ cd-inverted;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d5f43fe..d34469c 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -16,7 +16,3 @@
regulator-always-on;
};
-mmc1 {
- status = okay;
- vmmc-supply = ldo3_reg;
-};
--
1.8.2.1
--
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 2/4] am335x-boneblack: add eMMC DT entry
The pinmux is specified in am335x-bone-common.dtsi to be reused by the eMMC
cape.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v2:
add missing pinmux entries
Changes since v1:
dropped the ti,non-removable entry per Sekhars request
arch/arm/boot/dts/am335x-bone-common.dtsi | 22 ++
arch/arm/boot/dts/am335x-boneblack.dts| 14 ++
2 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index ced256c..cfec441 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -112,6 +112,21 @@
0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
;
};
+
+ emmc_pins: pinmux_emmc_pins {
+ pinctrl-single,pins =
+ 0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk, INPUT_PULLUP | MODE2 */
+ 0x84 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_csn2.mmc1_cmd, INPUT_PULLUP | MODE2 */
+ 0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0, INPUT_PULLUP | MODE1 */
+ 0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1, INPUT_PULLUP | MODE1 */
+ 0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2, INPUT_PULLUP | MODE1 */
+ 0x0c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad3.mmc1_dat3, INPUT_PULLUP | MODE1 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad4.mmc1_dat4, INPUT_PULLUP | MODE1 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad5.mmc1_dat5, INPUT_PULLUP | MODE1 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad6.mmc1_dat6, INPUT_PULLUP | MODE1 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad7.mmc1_dat7, INPUT_PULLUP | MODE1 */
+ ;
+ };
};
ocp {
@@ -241,6 +256,13 @@
regulator-always-on;
};
};
+
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 197cadf..f4703cf 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -15,3 +15,17 @@
regulator-max-microvolt = 180;
regulator-always-on;
};
+
+mmc1 {
+ vmmc-supply = vmmcsd_fixed;
+};
+
+mmc2 {
+ vmmc-supply = vmmcsd_fixed;
+ pinctrl-names = default;
+ pinctrl-0 = emmc_pins;
+ bus-width = 8;
+ status = okay;
+ ti,vcc-aux-disable-is-sleep;
+};
+
--
1.8.2.1
--
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 4/4] ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers
This matches the vendor 3.8.x configuration that is shipping with the boards.
The LED layout is now:
USR0: heartbeat
USR1: mmc0 (micro-SD slot)
USR2: cpu0
USR3: mmc1 (eMMC)
The cpu0 triggers was put inbetween the mmc triggers to make is easier to see
where the disk activity is.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 80407ff..3057f30 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -203,12 +203,14 @@
led@4 {
label = beaglebone:green:usr2;
gpios = gpio1 23 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = cpu0;
default-state = off;
};
led@5 {
label = beaglebone:green:usr3;
gpios = gpio1 24 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = mmc1;
default-state = off;
};
};
--
1.8.2.1
--
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
[PATCHv3 0/2] ARM: dts: Beaglebone MMC fixes
Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1 gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + 53aafdbc63c9b30c23f562855c8f359c0893bc40 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + 084f262cb1058e00cf082739cf7ee93cb70761c9 ARM: EDMA: Fix clearing of unused list for DT DMA resources + 6080eee0ef0ee3ab235cc267a69a0a7d3673266e ARM: dts: add AM33XX EDMA support + 7312f68fb49202b65498865bd64680c95ec2f7ea ARM: dts: add AM33XX SPI DMA support + 5580c3d400cefad5a1eb3c5a8e467353e22d526e ARM: dts: add AM33XX MMC support and documentation + a11eddaa0a89c24d2b9768a82519ac096bb793f1 arm: bone: dts: add CD for mmc1 + b1e87bfc52775c2666b6c4a89d409193319d33f2 am335x-boneblack: add eMMC DT entry + 090e095b74ba211b2cfbd2c87ae06c52d151453d ARM: am335x-bone-common: switch mmc1 to 4-bit mode + 39f747078f0b01724cfa94ce19fd2e6029ac0bee ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline Changes since v2: Missing pinmux entries for eMMC added Changes since v1: Removed ti,non-removable entry from eMMC node, see http://marc.info/?l=linux-arm-kernelm=137889435710552w=2 --- Alexander Holler (1): arm: bone: dts: add CD for mmc1 Koen Kooi (3): am335x-boneblack: add eMMC DT entry ARM: am335x-bone-common: switch mmc1 to 4-bit mode ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers arch/arm/boot/dts/am335x-bone-common.dtsi | 39 +++ arch/arm/boot/dts/am335x-bone.dts | 4 arch/arm/boot/dts/am335x-boneblack.dts| 14 +++ 3 files changed, 53 insertions(+), 4 deletions(-) -- 1.8.2.1 -- 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 3/4] ARM: am335x-bone-common: switch mmc1 to 4-bit mode
The micro-SD slot hooks up all four data pins so lets' use them.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index cfec441..80407ff 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -290,6 +290,7 @@
mmc1 {
status = okay;
+ bus-width = 0x4;
vmmc-supply = ldo3_reg;
pinctrl-names = default;
pinctrl-0 = mmc1_pins;
--
1.8.2.1
--
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 v4 0/2] ARM: dts: Beaglebone MMC fixes
Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1 gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + 564fc88cc64387af5312e2abd8019c75a13223b2 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + e5133ed98acc1c3e01c370b851041a8ca629cd15 ARM: EDMA: Fix clearing of unused list for DT DMA resources + ac71bb58605d3bdd5d14af770a639fb3ff11c612 ARM: dts: add AM33XX EDMA support + 31a8270a299c57c7de7510f44d9dc36fd1787243 ARM: dts: add AM33XX SPI DMA support + 4fa0a4cb9ea17da30cf43085c03e5ec1361a4fc2 ARM: dts: add AM33XX MMC support and documentation + 0553f50bd45f019a0cc11050e2f20bddbf07dfe0 ARM: dts: am335x-bone: add CD for mmc1 + 7d64f765630a2921a63b82f93f9959a6de37f29d ARM: dts: am335x-boneblack: add eMMC DT entry + dc96cd4003e2668d8ec7e7fe19e402e97a198f81 ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode + f8262e78830cda56c936724549ba9f04e312 ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline Changes since v3: Addressed Nishants nitpicks for commit messages Addressed Russ' comments about moving LDO3 for mmc1 out of the common dtsi Changes since v2: Missing pinmux entries for eMMC added Changes since v1: Removed ti,non-removable entry from eMMC node, see http://marc.info/?l=linux-arm-kernelm=137889435710552w=2 --- Alexander Holler (1): arm: bone: dts: add CD for mmc1 Koen Kooi (3): am335x-boneblack: add eMMC DT entry ARM: am335x-bone-common: switch mmc1 to 4-bit mode ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers arch/arm/boot/dts/am335x-bone-common.dtsi | 39 +++ arch/arm/boot/dts/am335x-bone.dts | 1 - arch/arm/boot/dts/am335x-boneblack.dts| 14 +++ 3 files changed, 53 insertions(+), 1 deletion(-) -- 1.8.2.1 -- 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 v4 1/4] ARM: dts: am335x-bone: add CD for mmc1
From: Alexander Holler hol...@ahsoftware.de
This enables the use of MMC cards even when no card was inserted at boot.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 ++
arch/arm/boot/dts/am335x-bone.dts | 1 -
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2f66ded..0d95d54 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -107,6 +107,12 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
+ ;
+ };
};
ocp {
@@ -260,3 +266,11 @@
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
};
+
+mmc1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+ cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
+ cd-inverted;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d5f43fe..0d63348 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -17,6 +17,5 @@
};
mmc1 {
- status = okay;
vmmc-supply = ldo3_reg;
};
--
1.8.2.1
--
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 v4 4/4] ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers
This matches the vendor 3.8.x configuration that is shipping with the boards.
The LED layout is now:
USR0: heartbeat
USR1: mmc0 (micro-SD slot)
USR2: cpu0
USR3: mmc1 (eMMC)
The cpu0 triggers was put in between the mmc triggers to make is easier to see
where the disk activity is.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 303df81..adce9fe 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -204,12 +204,14 @@
led@4 {
label = beaglebone:green:usr2;
gpios = gpio1 23 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = cpu0;
default-state = off;
};
led@5 {
label = beaglebone:green:usr3;
gpios = gpio1 24 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = mmc1;
default-state = off;
};
};
--
1.8.2.1
--
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 v4 3/4] ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode
The micro-SD slot hooks up all four data pins so lets' use them.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bc8d1a2..303df81 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -291,6 +291,7 @@
mmc1 {
status = okay;
+ bus-width = 0x4;
pinctrl-names = default;
pinctrl-0 = mmc1_pins;
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
--
1.8.2.1
--
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 v4 2/4] ARM: dts: am335x-boneblack: add eMMC DT entry
The pinmux is specified in am335x-bone-common.dtsi to be reused by the eMMC
cape.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 22 ++
arch/arm/boot/dts/am335x-boneblack.dts| 14 ++
2 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 0d95d54..bc8d1a2 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -113,6 +113,21 @@
0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
;
};
+
+ emmc_pins: pinmux_emmc_pins {
+ pinctrl-single,pins =
+ 0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk, INPUT_PULLUP | MODE2 */
+ 0x84 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_csn2.mmc1_cmd, INPUT_PULLUP | MODE2 */
+ 0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0, INPUT_PULLUP | MODE1 */
+ 0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1, INPUT_PULLUP | MODE1 */
+ 0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2, INPUT_PULLUP | MODE1 */
+ 0x0c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad3.mmc1_dat3, INPUT_PULLUP | MODE1 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad4.mmc1_dat4, INPUT_PULLUP | MODE1 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad5.mmc1_dat5, INPUT_PULLUP | MODE1 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad6.mmc1_dat6, INPUT_PULLUP | MODE1 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad7.mmc1_dat7, INPUT_PULLUP | MODE1 */
+ ;
+ };
};
ocp {
@@ -242,6 +257,13 @@
regulator-always-on;
};
};
+
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 197cadf..f4703cf 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -15,3 +15,17 @@
regulator-max-microvolt = 180;
regulator-always-on;
};
+
+mmc1 {
+ vmmc-supply = vmmcsd_fixed;
+};
+
+mmc2 {
+ vmmc-supply = vmmcsd_fixed;
+ pinctrl-names = default;
+ pinctrl-0 = emmc_pins;
+ bus-width = 8;
+ status = okay;
+ ti,vcc-aux-disable-is-sleep;
+};
+
--
1.8.2.1
--
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 0/3] ARM: dts: Enable EDMA, MMC and SPI on AM33XX for v3.13
Op 11 sep. 2013, om 08:00 heeft Joel Fernandes jo...@ti.com het volgende geschreven: On 09/11/2013 12:18 AM, Koen Kooi wrote: Op 10 sep. 2013, om 22:14 heeft Joel Fernandes jo...@ti.com het volgende geschreven: On 09/10/2013 02:39 PM, Koen Kooi wrote: Op 10 sep. 2013, om 21:24 heeft Joel Fernandes jo...@ti.com het volgende geschreven: Here are last few patches required to add EDMA and MMC/SPI support for AM33xx. Now that all dependent DMA patches and fixes are in linux next or mainline, except for [1] which should go in for 3.12 -rc cycle, it is safe to enable MMC and SPI support and this patch series enables it. These are originally Matt Porter's patches with changes to make it work with recent kernels, addition of irq, memory resources and enable other extra properties. These patches should cleanly apply on master branch after Koen's patch [2] for basic BBB DT support is applied. MMC support is enabled for: Beaglebone, AM335x EVM and EVM-SK boards. MMC support for BBB is intentionally not added due to custom fixes and other patches that are in Koen's tree and which will be separately submitted by him. Correct, but your patches for MMC support on BBW are missing the card detect entries to make it hotplug work. I thought it was determined that this would be submitted by you separately after rebasing as we discussed [1] and [2]. I have no problem submitting that, I just think it's weird that the patch you submitted contains a known broken version for BBW. There's nothing broken about $subject series. Please don't confuse maintainers by using wrong words like that. This series is perfectly OK as such to be merged. But plugging in an SD card doesn't work in this series, I'd call that broken. Further, I am puzzled by all this noise because card-detect additions were initially agreed to be posted separately by you along with other custom DTS for BBW MMC. I agreed to post the mmc fixes needed for BBW and BBB, so I assumed you'd drop all beaglebone entries from your series. Its obvious I wouldn't squash patches that we _agreed_ you would send out- and that are especially additions than any real fixes. Hopefully this makes it clear, if you need any help please let me know. Right, so now your patch series will add a half-assed DT entry which only works if the uSD card is present at boot. Anyway, fixup series underway already Thanks! -Joel [1] https://lkml.org/lkml/2013/9/6/183 [2] http://marc.info/?l=linux-omapm=137879246709612w=2 Regards, -Joel -- 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: Beaglebone MMC fixes
Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + c8436cd15251ea42c7f2decd1cc972de536a7573 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + 34596cb58346612101b168b34b7ee75b8b0e9500 ARM: EDMA: Fix clearing of unused list for DT DMA resources + af7f273dfbeeec7669c01a81b8c02f4af2fcf1b9 ARM: dts: add AM33XX EDMA support + a85f9acc8f48a7cb1a07fb93fcba7bd43aa9c853 ARM: dts: add AM33XX SPI DMA support + 72a42fa0b42051251c554d9f75f42b3e9bc6ec8a ARM: dts: add AM33XX MMC support and documentation + 93205a3735613d674b209c3c75ad3e0a7d6be136 arm: bone: dts: add CD for mmc1 + b1bd98705a2da3d02f197d29ca040008ad8c662c am335x-boneblack: add eMMC DT entry Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline --- Alexander Holler (1): arm: bone: dts: add CD for mmc1 Koen Kooi (1): am335x-boneblack: add eMMC DT entry arch/arm/boot/dts/am335x-bone-common.dtsi | 21 + arch/arm/boot/dts/am335x-bone.dts | 4 arch/arm/boot/dts/am335x-boneblack.dts| 15 +++ 3 files changed, 36 insertions(+), 4 deletions(-) -- 1.8.2.1 -- 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 1/2] arm: bone: dts: add CD for mmc1
From: Alexander Holler hol...@ahsoftware.de
This enables the use of MMC cards even when no card was inserted at boot.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 ++
arch/arm/boot/dts/am335x-bone.dts | 4
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2f66ded..ced256c 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -107,6 +107,11 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
+ ;
+ };
};
ocp {
@@ -260,3 +265,12 @@
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = ldo3_reg;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+ cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
+ cd-inverted;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d5f43fe..d34469c 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -16,7 +16,3 @@
regulator-always-on;
};
-mmc1 {
- status = okay;
- vmmc-supply = ldo3_reg;
-};
--
1.8.2.1
--
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 2/2] am335x-boneblack: add eMMC DT entry
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 7 +++
arch/arm/boot/dts/am335x-boneblack.dts| 15 +++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index ced256c..9c61fef 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -241,6 +241,13 @@
regulator-always-on;
};
};
+
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 197cadf..c09947a 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -15,3 +15,18 @@
regulator-max-microvolt = 180;
regulator-always-on;
};
+
+mmc1 {
+ vmmc-supply = vmmcsd_fixed;
+};
+
+mmc2 {
+ vmmc-supply = vmmcsd_fixed;
+ pinctrl-names = default;
+ pinctrl-0 = emmc_pins;
+ bus-width = 8;
+ ti,non-removable;
+ status = okay;
+ ti,vcc-aux-disable-is-sleep;
+};
+
--
1.8.2.1
--
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] am335x-boneblack: add eMMC DT entry
Op 11 sep. 2013, om 12:06 heeft Sekhar Nori nsek...@ti.com het volgende
geschreven:
On Wednesday 11 September 2013 11:42 AM, Koen Kooi wrote:
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 7 +++
arch/arm/boot/dts/am335x-boneblack.dts| 15 +++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index ced256c..9c61fef 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -241,6 +241,13 @@
regulator-always-on;
};
};
+
+vmmcsd_fixed: fixedregulator@0 {
+compatible = regulator-fixed;
+regulator-name = vmmcsd_fixed;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+};
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 197cadf..c09947a 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -15,3 +15,18 @@
regulator-max-microvolt = 180;
regulator-always-on;
};
+
+mmc1 {
+vmmc-supply = vmmcsd_fixed;
+};
+
+mmc2 {
+vmmc-supply = vmmcsd_fixed;
+pinctrl-names = default;
+pinctrl-0 = emmc_pins;
+bus-width = 8;
+ti,non-removable;
There is a standard binding available for this: non-removable
There should not be a need to introduce a TI specific binding for this
(I know this is not your fault).
I will send a patch to change the existing .dts files and update the
driver - can you drop this line for now so we don't introduce more
incompatibilities? I can send a patch adding non-removable to this
node as part of my clean-up series.
Sure, I'll send a v2 shortly. Thank you very much for killing another ti,
prefixed node!
regards,
Koen
--
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
[PATCHv2 0/2] ARM: dts: Beaglebone MMC fixes
Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + c8436cd15251ea42c7f2decd1cc972de536a7573 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + 34596cb58346612101b168b34b7ee75b8b0e9500 ARM: EDMA: Fix clearing of unused list for DT DMA resources + af7f273dfbeeec7669c01a81b8c02f4af2fcf1b9 ARM: dts: add AM33XX EDMA support + a85f9acc8f48a7cb1a07fb93fcba7bd43aa9c853 ARM: dts: add AM33XX SPI DMA support + 72a42fa0b42051251c554d9f75f42b3e9bc6ec8a ARM: dts: add AM33XX MMC support and documentation + 93205a3735613d674b209c3c75ad3e0a7d6be136 arm: bone: dts: add CD for mmc1 + b1bd98705a2da3d02f197d29ca040008ad8c662c am335x-boneblack: add eMMC DT entry Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline Changes since v1: Removed ti,non-removable entry from eMMC node, see http://marc.info/?l=linux-arm-kernelm=137889435710552w=2 --- Alexander Holler (1): arm: bone: dts: add CD for mmc1 Koen Kooi (1): am335x-boneblack: add eMMC DT entry arch/arm/boot/dts/am335x-bone-common.dtsi | 21 + arch/arm/boot/dts/am335x-bone.dts | 4 arch/arm/boot/dts/am335x-boneblack.dts| 15 +++ 3 files changed, 36 insertions(+), 4 deletions(-) -- 1.8.2.1 -- 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
[PATCHv2 1/2] arm: bone: dts: add CD for mmc1
From: Alexander Holler hol...@ahsoftware.de
This enables the use of MMC cards even when no card was inserted at boot.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v1:
None, simple repost
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 ++
arch/arm/boot/dts/am335x-bone.dts | 4
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2f66ded..ced256c 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -107,6 +107,11 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
+ ;
+ };
};
ocp {
@@ -260,3 +265,12 @@
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = ldo3_reg;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+ cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
+ cd-inverted;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d5f43fe..d34469c 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -16,7 +16,3 @@
regulator-always-on;
};
-mmc1 {
- status = okay;
- vmmc-supply = ldo3_reg;
-};
--
1.8.2.1
--
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
[PATCHv2 2/2] am335x-boneblack: add eMMC DT entry
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v1:
dropped the ti,non-removable entry per Sehkars request
arch/arm/boot/dts/am335x-bone-common.dtsi | 7 +++
arch/arm/boot/dts/am335x-boneblack.dts| 14 ++
2 files changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index ced256c..9c61fef 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -241,6 +241,13 @@
regulator-always-on;
};
};
+
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 197cadf..f4703cf 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -15,3 +15,17 @@
regulator-max-microvolt = 180;
regulator-always-on;
};
+
+mmc1 {
+ vmmc-supply = vmmcsd_fixed;
+};
+
+mmc2 {
+ vmmc-supply = vmmcsd_fixed;
+ pinctrl-names = default;
+ pinctrl-0 = emmc_pins;
+ bus-width = 8;
+ status = okay;
+ ti,vcc-aux-disable-is-sleep;
+};
+
--
1.8.2.1
--
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 0/3] ARM: dts: Enable EDMA, MMC and SPI on AM33XX for v3.13
Op 10 sep. 2013, om 21:24 heeft Joel Fernandes jo...@ti.com het volgende geschreven: Here are last few patches required to add EDMA and MMC/SPI support for AM33xx. Now that all dependent DMA patches and fixes are in linux next or mainline, except for [1] which should go in for 3.12 -rc cycle, it is safe to enable MMC and SPI support and this patch series enables it. These are originally Matt Porter's patches with changes to make it work with recent kernels, addition of irq, memory resources and enable other extra properties. These patches should cleanly apply on master branch after Koen's patch [2] for basic BBB DT support is applied. MMC support is enabled for: Beaglebone, AM335x EVM and EVM-SK boards. MMC support for BBB is intentionally not added due to custom fixes and other patches that are in Koen's tree and which will be separately submitted by him. Correct, but your patches for MMC support on BBW are missing the card detect entries to make it hotplug work. -- 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 0/3] ARM: dts: Enable EDMA, MMC and SPI on AM33XX for v3.13
Op 10 sep. 2013, om 22:14 heeft Joel Fernandes jo...@ti.com het volgende geschreven: On 09/10/2013 02:39 PM, Koen Kooi wrote: Op 10 sep. 2013, om 21:24 heeft Joel Fernandes jo...@ti.com het volgende geschreven: Here are last few patches required to add EDMA and MMC/SPI support for AM33xx. Now that all dependent DMA patches and fixes are in linux next or mainline, except for [1] which should go in for 3.12 -rc cycle, it is safe to enable MMC and SPI support and this patch series enables it. These are originally Matt Porter's patches with changes to make it work with recent kernels, addition of irq, memory resources and enable other extra properties. These patches should cleanly apply on master branch after Koen's patch [2] for basic BBB DT support is applied. MMC support is enabled for: Beaglebone, AM335x EVM and EVM-SK boards. MMC support for BBB is intentionally not added due to custom fixes and other patches that are in Koen's tree and which will be separately submitted by him. Correct, but your patches for MMC support on BBW are missing the card detect entries to make it hotplug work. I thought it was determined that this would be submitted by you separately after rebasing as we discussed [1] and [2]. I have no problem submitting that, I just think it's weird that the patch you submitted contains a known broken version for BBW. [1] https://lkml.org/lkml/2013/9/6/183 [2] http://marc.info/?l=linux-omapm=137879246709612w=2 Regards, -Joel -- 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
[PATCHv4] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added,
so create a common dtsi both can use.
IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI
transceiver
after a dozen boots with an uSD card inserted because LDO will be at 3.3V
instead
of 1.8.
MMC support for AM335x still isn't in, so only the LDO change has been added.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
Tested-by: Tom Rini tr...@ti.com
Tested-by: Matt Porter matt.por...@linaro.org
---
Changes since v3:
removed stray whitespace, spotted by Matt Porter
added CC: stable
Changes since v2:
Updated commit message to point out that the existing DT will damage
the board.
Changes since v1:
Added the Makefile entry for the new dts
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/am335x-bone-common.dtsi | 262 ++
arch/arm/boot/dts/am335x-bone.dts | 256 +
arch/arm/boot/dts/am335x-boneblack.dts| 17 ++
4 files changed, 281 insertions(+), 255 deletions(-)
create mode 100644 arch/arm/boot/dts/am335x-bone-common.dtsi
create mode 100644 arch/arm/boot/dts/am335x-boneblack.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 000cf76..d515c54 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -183,6 +183,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
+ am335x-boneblack.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
new file mode 100644
index 000..2f66ded
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -0,0 +1,262 @@
+/*
+ * Copyright (C) 2012 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.
+ */
+
+/ {
+ model = TI AM335x BeagleBone;
+ compatible = ti,am335x-bone, ti,am33xx;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = dcdc2_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = default;
+ pinctrl-0 = clkout2_pin;
+
+ user_leds_s0: user_leds_s0 {
+ pinctrl-single,pins =
+ 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a5.gpio1_21 */
+ 0x58 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a6.gpio1_22 */
+ 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a7.gpio1_23 */
+ 0x60 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a8.gpio1_24 */
+ ;
+ };
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
+ ;
+ };
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
+ 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
+ ;
+ };
+
+ clkout2_pin: pinmux_clkout2_pin {
+ pinctrl-single,pins =
+ 0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
xdma_event_intr1.clkout2 */
+ ;
+ };
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x110 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxerr.mii1_rxerr */
+ 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txen.mii1_txen */
+ 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxdv.mii1_rxdv */
+ 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd3.mii1_txd3 */
+ 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd2.mii1_txd2 */
+ 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd1.mii1_txd1 */
+ 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd0.mii1_txd0 */
+ 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_txclk.mii1_txclk
Re: [PATCHv4] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
Op 9 sep. 2013, om 16:15 heeft Felipe Balbi ba...@ti.com het volgende geschreven: Hi, On Mon, Sep 09, 2013 at 03:45:50PM +0200, Koen Kooi wrote: The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added, so create a common dtsi both can use. IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. MMC support for AM335x still isn't in, so only the LDO change has been added. Signed-off-by: Koen Kooi k...@dominion.thruhere.net Tested-by: Tom Rini tr...@ti.com Tested-by: Matt Porter matt.por...@linaro.org not entirelly related to $SUBJECT but having HDMI listed in BBB DTS will prevent the use of RF cape, no ? Complete and utter lack of software from TI for the RF cape is preventing the RF cape from working regardless of HDMI entries.-- 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: OMAP2+: am335x-bone*: add DT for BeagleBone Black
The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added,
so create a common dtsi both can use.
IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI
transceiver
after a dozen boots with an uSD card inserted because LDO will be at 3.3V
instead
of 1.8.
MMC support for AM335x still isn't in, so only the LDO change has been added.
Cc: sta...@vger.kernel.org
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
Tested-by: Tom Rini tr...@ti.com
Tested-by: Matt Porter matt.por...@linaro.org
---
Changes since v4:
attempting to correctly to the cc: stable@ thing
Changes since v3:
removed stray whitespace, spotted by Matt Porter
added CC: stable
Changes since v2:
Updated commit message to point out that the existing DT will damage
the board.
Changes since v1:
Added the Makefile entry for the new dts
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/am335x-bone-common.dtsi | 262 ++
arch/arm/boot/dts/am335x-bone.dts | 256 +
arch/arm/boot/dts/am335x-boneblack.dts| 17 ++
4 files changed, 281 insertions(+), 255 deletions(-)
create mode 100644 arch/arm/boot/dts/am335x-bone-common.dtsi
create mode 100644 arch/arm/boot/dts/am335x-boneblack.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 000cf76..d515c54 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -183,6 +183,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
+ am335x-boneblack.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
new file mode 100644
index 000..2f66ded
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -0,0 +1,262 @@
+/*
+ * Copyright (C) 2012 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.
+ */
+
+/ {
+ model = TI AM335x BeagleBone;
+ compatible = ti,am335x-bone, ti,am33xx;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = dcdc2_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = default;
+ pinctrl-0 = clkout2_pin;
+
+ user_leds_s0: user_leds_s0 {
+ pinctrl-single,pins =
+ 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a5.gpio1_21 */
+ 0x58 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a6.gpio1_22 */
+ 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a7.gpio1_23 */
+ 0x60 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a8.gpio1_24 */
+ ;
+ };
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
+ ;
+ };
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
+ 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
+ ;
+ };
+
+ clkout2_pin: pinmux_clkout2_pin {
+ pinctrl-single,pins =
+ 0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
xdma_event_intr1.clkout2 */
+ ;
+ };
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x110 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxerr.mii1_rxerr */
+ 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txen.mii1_txen */
+ 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxdv.mii1_rxdv */
+ 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd3.mii1_txd3 */
+ 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd2.mii1_txd2 */
+ 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd1.mii1_txd1 */
+ 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd0.mii1_txd0
Re: [PATCH] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
Op 9 sep. 2013, om 17:23 heeft Kevin Hilman khil...@linaro.org het volgende geschreven: Koen Kooi k...@dominion.thruhere.net writes: The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added, so create a common dtsi both can use. IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. MMC support for AM335x still isn't in, so only the LDO change has been added. Cc: sta...@vger.kernel.org Signed-off-by: Koen Kooi k...@dominion.thruhere.net Tested-by: Tom Rini tr...@ti.com Tested-by: Matt Porter matt.por...@linaro.org I guess the subject should've included v5? Yes, I blame it on being monday :) Also, if this is to be stable material, it will likely need rework since I don't think it will apply cleanly to older trees due to DT churn. Ah right, the preprocessor changes. We'll see what happens with the stable trees. Most older kernels are useless on am335x, but the just released 3.11 is dangerous enough to get this backported. Anyways, for this patch... Acked-by: Kevin Hilman khil...@linaro.org Even though I've probably already fried my HDMI transciever due to using the original DTS a lot more than a dozen times. (and to TI: yes, I'd accept a new BB black as a sympathy gift.) ;) Also, I tested this on both BBW and BBW: Tested-by: Kevin Hilman khil...@linaro.org Thanks! regards, Koen Benoit, assuming this looks good to you, can you queue this for v3.12-rc please? It applies to Linus' HEAD today (which has most of arm-soc merged), so it should apply cleanly on top of all your stuff. 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] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
Op 9 sep. 2013, om 20:27 heeft Joel Fernandes jo...@ti.com het volgende geschreven: On 09/09/2013 10:51 AM, Koen Kooi wrote: Op 9 sep. 2013, om 17:23 heeft Kevin Hilman khil...@linaro.org het volgende geschreven: Koen Kooi k...@dominion.thruhere.net writes: The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added, so create a common dtsi both can use. IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. MMC support for AM335x still isn't in, so only the LDO change has been added. Cc: sta...@vger.kernel.org Signed-off-by: Koen Kooi k...@dominion.thruhere.net Tested-by: Tom Rini tr...@ti.com Tested-by: Matt Porter matt.por...@linaro.org I guess the subject should've included v5? Yes, I blame it on being monday :) The series you're posting will require rebasing on the current MMC DT series that is being discussed last couple of weeks on the mailing list which were waiting until now as DMA support was missing. Now that DMA support is pulled in, it is safe to apply those patches so I will be reposting them shortly. Please hold off any changes until those patches are posted. This will avoid unnecessary conflicts. Or you can rebase on top of this patch since it has no dependencies *and* fixes blowing up boards. FWIW, git-rebase, git-cherry-pick and git-am -3 track the rename in my patch just fine.-- 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: OMAP2+: am335x-bone*: add DT for BeagleBone Black
Op 9 sep. 2013, om 21:50 heeft Joel Fernandes jo...@ti.com het volgende geschreven: On 09/09/2013 01:51 PM, Joel Fernandes wrote: On 09/09/2013 01:43 PM, Koen Kooi wrote: Op 9 sep. 2013, om 20:27 heeft Joel Fernandes jo...@ti.com het volgende geschreven: On 09/09/2013 10:51 AM, Koen Kooi wrote: Op 9 sep. 2013, om 17:23 heeft Kevin Hilman khil...@linaro.org het volgende geschreven: Koen Kooi k...@dominion.thruhere.net writes: The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added, so create a common dtsi both can use. IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. MMC support for AM335x still isn't in, so only the LDO change has been added. Cc: sta...@vger.kernel.org Signed-off-by: Koen Kooi k...@dominion.thruhere.net Tested-by: Tom Rini tr...@ti.com Tested-by: Matt Porter matt.por...@linaro.org I guess the subject should've included v5? Yes, I blame it on being monday :) The series you're posting will require rebasing on the current MMC DT series that is being discussed last couple of weeks on the mailing list which were waiting until now as DMA support was missing. Now that DMA support is pulled in, it is safe to apply those patches so I will be reposting them shortly. Please hold off any changes until those patches are posted. This will avoid unnecessary conflicts. Or you can rebase on top of this patch since it has no dependencies *and* fixes blowing up boards. FWIW, git-rebase, git-cherry-pick and git-am -3 track the rename in my patch just fine. That's fair enough, since Kevin Acked and Benoit is pulling it, I'm fine with rebasing on top of it and we avoid any merge conflicts. I noticed - there were still some comments from Felipe on the v4 series of this patch regarding RF cape and HDMI may be breaking it. How are you addressing that? Capes will never go into the .dts and HDMI support needs some serious patching before it can get enabled in the DT. And the RF cape isn't being sold since it has no sw support. No need to worry about things in the 3.15/3.16 timeframe. Unless you want this LDO3 fix not to go in ASAP. Joel, is there anything relevant *right now* blocking this patch going in? If not, please test it and add your Tested-by: line.-- 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: OMAP2+: am335x-bone*: add DT for BeagleBone Black
Op 10 sep. 2013, om 01:42 heeft Joel Fernandes jo...@ti.com het volgende geschreven: On 09/09/2013 03:12 PM, Joel Fernandes wrote: On 09/09/2013 03:00 PM, Koen Kooi wrote: Op 9 sep. 2013, om 21:50 heeft Joel Fernandes jo...@ti.com het volgende geschreven: On 09/09/2013 01:51 PM, Joel Fernandes wrote: On 09/09/2013 01:43 PM, Koen Kooi wrote: Op 9 sep. 2013, om 20:27 heeft Joel Fernandes jo...@ti.com het volgende geschreven: On 09/09/2013 10:51 AM, Koen Kooi wrote: Op 9 sep. 2013, om 17:23 heeft Kevin Hilman khil...@linaro.org het volgende geschreven: Koen Kooi k...@dominion.thruhere.net writes: The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added, so create a common dtsi both can use. IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. MMC support for AM335x still isn't in, so only the LDO change has been added. Cc: sta...@vger.kernel.org Signed-off-by: Koen Kooi k...@dominion.thruhere.net Tested-by: Tom Rini tr...@ti.com Tested-by: Matt Porter matt.por...@linaro.org I guess the subject should've included v5? Yes, I blame it on being monday :) The series you're posting will require rebasing on the current MMC DT series that is being discussed last couple of weeks on the mailing list which were waiting until now as DMA support was missing. Now that DMA support is pulled in, it is safe to apply those patches so I will be reposting them shortly. Please hold off any changes until those patches are posted. This will avoid unnecessary conflicts. Or you can rebase on top of this patch since it has no dependencies *and* fixes blowing up boards. FWIW, git-rebase, git-cherry-pick and git-am -3 track the rename in my patch just fine. That's fair enough, since Kevin Acked and Benoit is pulling it, I'm fine with rebasing on top of it and we avoid any merge conflicts. I noticed - there were still some comments from Felipe on the v4 series of this patch regarding RF cape and HDMI may be breaking it. How are you addressing that? Capes will never go into the .dts and HDMI support needs some serious patching before it can get enabled in the DT. And the RF cape isn't being sold since it has no sw support. No need to worry about things in the 3.15/3.16 timeframe. Unless you want this LDO3 fix not to go in ASAP. Joel, is there anything relevant *right now* blocking this patch going in? If not, please test it and add your Tested-by: line. We don't merge things in hurry and focus is to do things the right way.. I just want to make sure that all possible comments have been addressed. Otherwise patch looks OK and hope everyone else thinks so too. I am dealing with some merge conflicts right now with my series on top of this though, but they should be easy enough to fix up. That's delaying my testing, but otherwise as such I don't have any objection to this patch (provided the conclusion is that all comments have been addressed..). Thanks! Koen, One note though, since I don't use HDMI (or BBB much for that matter), I was ok with taking a risk of upping the ldo3 regulator voltage to 3.3v on my board which I needed to do to get to the boot prompt. I applied my AM335x DMA and MMC patches and tried to boot with rootfs as MMC1. With 1.8v, I get the following during boot: [2.236043] mmc0: host doesn't support card's voltages [2.241659] mmc0: error -22 whilst initialising SD card That's strange because I do have an SDHC card. With 3.3v it works fine. I will add a note about this to my series. Since this more of an MMC issue than anything, and your patch series doesn't enable MMC, you can add my tested-by: Tested-by: Joel Fernandes jo...@ti.com Later on, the regulator voltage may need to be tweaked for MMC support. See https://lkml.org/lkml/2013/9/6/95 and https://lkml.org/lkml/2013/9/6/183-- 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
[PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added,
so create a common dtsi both can use.
IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI
transceiver
after a dozen boots with an uSD card inserted because LDO will be at 3.3V
instead
of 1.8.
MMC support for AM335x still isn't in, so only the LDO change has been added.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since 2:
Updated commit message to point out that the existing DT will damage
the board.
Changes since v1:
Added the Makefile entry for the new dts
arch/arm/boot/dts/Makefile | 1 +
.../{am335x-bone.dts = am335x-bone-common.dtsi} | 3 -
arch/arm/boot/dts/am335x-bone.dts | 256 +
arch/arm/boot/dts/am335x-boneblack.dts | 18 ++
4 files changed, 20 insertions(+), 258 deletions(-)
copy arch/arm/boot/dts/{am335x-bone.dts = am335x-bone-common.dtsi} (99%)
create mode 100644 arch/arm/boot/dts/am335x-boneblack.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9a..b7c0c52 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -171,6 +171,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
+ am335x-boneblack.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone-common.dtsi
similarity index 99%
copy from arch/arm/boot/dts/am335x-bone.dts
copy to arch/arm/boot/dts/am335x-bone-common.dtsi
index d318987..2f66ded 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -5,9 +5,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-/dts-v1/;
-
-#include am33xx.dtsi
/ {
model = TI AM335x BeagleBone;
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d318987..7993c48 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -8,258 +8,4 @@
/dts-v1/;
#include am33xx.dtsi
-
-/ {
- model = TI AM335x BeagleBone;
- compatible = ti,am335x-bone, ti,am33xx;
-
- cpus {
- cpu@0 {
- cpu0-supply = dcdc2_reg;
- };
- };
-
- memory {
- device_type = memory;
- reg = 0x8000 0x1000; /* 256 MB */
- };
-
- am33xx_pinmux: pinmux@44e10800 {
- pinctrl-names = default;
- pinctrl-0 = clkout2_pin;
-
- user_leds_s0: user_leds_s0 {
- pinctrl-single,pins =
- 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a5.gpio1_21 */
- 0x58 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a6.gpio1_22 */
- 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a7.gpio1_23 */
- 0x60 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a8.gpio1_24 */
- ;
- };
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins =
- 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
- 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
- ;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins =
- 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
- 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
- ;
- };
-
- clkout2_pin: pinmux_clkout2_pin {
- pinctrl-single,pins =
- 0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
xdma_event_intr1.clkout2 */
- ;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins =
- /* Slave 1 */
- 0x110 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxerr.mii1_rxerr */
- 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txen.mii1_txen */
- 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxdv.mii1_rxdv */
- 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd3.mii1_txd3 */
- 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd2.mii1_txd2 */
- 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd1.mii1_txd1 */
- 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE0
[PATCH] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added,
so create a common dtsi both can use. MMC support for AM335x still isn't in, so
only the LDO change has been added.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
.../{am335x-bone.dts = am335x-bone-common.dtsi} | 3 -
arch/arm/boot/dts/am335x-bone.dts | 256 +
arch/arm/boot/dts/am335x-boneblack.dts | 18 ++
3 files changed, 19 insertions(+), 258 deletions(-)
copy arch/arm/boot/dts/{am335x-bone.dts = am335x-bone-common.dtsi} (99%)
create mode 100644 arch/arm/boot/dts/am335x-boneblack.dts
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone-common.dtsi
similarity index 99%
copy from arch/arm/boot/dts/am335x-bone.dts
copy to arch/arm/boot/dts/am335x-bone-common.dtsi
index d318987..2f66ded 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -5,9 +5,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-/dts-v1/;
-
-#include am33xx.dtsi
/ {
model = TI AM335x BeagleBone;
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d318987..7993c48 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -8,258 +8,4 @@
/dts-v1/;
#include am33xx.dtsi
-
-/ {
- model = TI AM335x BeagleBone;
- compatible = ti,am335x-bone, ti,am33xx;
-
- cpus {
- cpu@0 {
- cpu0-supply = dcdc2_reg;
- };
- };
-
- memory {
- device_type = memory;
- reg = 0x8000 0x1000; /* 256 MB */
- };
-
- am33xx_pinmux: pinmux@44e10800 {
- pinctrl-names = default;
- pinctrl-0 = clkout2_pin;
-
- user_leds_s0: user_leds_s0 {
- pinctrl-single,pins =
- 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a5.gpio1_21 */
- 0x58 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a6.gpio1_22 */
- 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a7.gpio1_23 */
- 0x60 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a8.gpio1_24 */
- ;
- };
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins =
- 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
- 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
- ;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins =
- 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
- 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
- ;
- };
-
- clkout2_pin: pinmux_clkout2_pin {
- pinctrl-single,pins =
- 0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
xdma_event_intr1.clkout2 */
- ;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins =
- /* Slave 1 */
- 0x110 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxerr.mii1_rxerr */
- 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txen.mii1_txen */
- 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxdv.mii1_rxdv */
- 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd3.mii1_txd3 */
- 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd2.mii1_txd2 */
- 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd1.mii1_txd1 */
- 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd0.mii1_txd0 */
- 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_txclk.mii1_txclk */
- 0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxclk.mii1_rxclk */
- 0x134 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd3.mii1_rxd3 */
- 0x138 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd2.mii1_rxd2 */
- 0x13c (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd1.mii1_rxd1 */
- 0x140 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd0.mii1_rxd0 */
- ;
- };
-
- cpsw_sleep: cpsw_sleep {
- pinctrl-single,pins =
- /* Slave 1 reset value
Re: [PATCH] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
Op 6 sep. 2013, om 08:57 heeft George Cherian george.cher...@ti.com het
volgende geschreven:
On 9/6/2013 12:03 PM, Koen Kooi wrote:
The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI
added,
so create a common dtsi both can use. MMC support for AM335x still isn't in,
so
only the LDO change has been added.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
.../{am335x-bone.dts = am335x-bone-common.dtsi} | 3 -
arch/arm/boot/dts/am335x-bone.dts | 256
+
arch/arm/boot/dts/am335x-boneblack.dts | 18 ++
3 files changed, 19 insertions(+), 258 deletions(-)
copy arch/arm/boot/dts/{am335x-bone.dts = am335x-bone-common.dtsi} (99%)
create mode 100644 arch/arm/boot/dts/am335x-boneblack.dts
How did you test am335x-boneblack.dtb? where are the Makefile changes for
boneblack?
Ah, I missed the makefile in my commit. I have a bunch of other patches on top
to make more stuff work.
[..]
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2012 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.
+ */
+/dts-v1/;
+
+#include am33xx.dtsi
Why cant we add am33xx.dtsi in am335x-bone-common.dtsi ?
That didn't work when I tried it. It did work before the preprocessor changes
when using /include/
+#include am335x-bone-common.dtsi
+
+ldo3_reg {
+regulator-min-microvolt = 180;
+regulator-max-microvolt = 180;
+regulator-always-on;
+};
+
With this ldo values mmc was not working for me on Boneblack.
got it working with
ldo3_reg {
regulator-min-microvolt = 180;
regulator-max-microvolt = 330;
regulator-always-on;
};
That LDO is shared, the other consumer will get fried if you use 3.3V. I forget
if it's DDR3 or HDMI.--
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
[PATCHv2] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added,
so create a common dtsi both can use. MMC support for AM335x still isn't in, so
only the LDO change has been added.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v1:
Added the Makefile entry for the new dts
arch/arm/boot/dts/Makefile | 1 +
.../{am335x-bone.dts = am335x-bone-common.dtsi} | 3 -
arch/arm/boot/dts/am335x-bone.dts | 256 +
arch/arm/boot/dts/am335x-boneblack.dts | 18 ++
4 files changed, 20 insertions(+), 258 deletions(-)
copy arch/arm/boot/dts/{am335x-bone.dts = am335x-bone-common.dtsi} (99%)
create mode 100644 arch/arm/boot/dts/am335x-boneblack.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9a..b7c0c52 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -171,6 +171,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
+ am335x-boneblack.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone-common.dtsi
similarity index 99%
copy from arch/arm/boot/dts/am335x-bone.dts
copy to arch/arm/boot/dts/am335x-bone-common.dtsi
index d318987..2f66ded 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -5,9 +5,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-/dts-v1/;
-
-#include am33xx.dtsi
/ {
model = TI AM335x BeagleBone;
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d318987..7993c48 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -8,258 +8,4 @@
/dts-v1/;
#include am33xx.dtsi
-
-/ {
- model = TI AM335x BeagleBone;
- compatible = ti,am335x-bone, ti,am33xx;
-
- cpus {
- cpu@0 {
- cpu0-supply = dcdc2_reg;
- };
- };
-
- memory {
- device_type = memory;
- reg = 0x8000 0x1000; /* 256 MB */
- };
-
- am33xx_pinmux: pinmux@44e10800 {
- pinctrl-names = default;
- pinctrl-0 = clkout2_pin;
-
- user_leds_s0: user_leds_s0 {
- pinctrl-single,pins =
- 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a5.gpio1_21 */
- 0x58 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a6.gpio1_22 */
- 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a7.gpio1_23 */
- 0x60 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a8.gpio1_24 */
- ;
- };
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins =
- 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
- 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
- ;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins =
- 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
- 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
- ;
- };
-
- clkout2_pin: pinmux_clkout2_pin {
- pinctrl-single,pins =
- 0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
xdma_event_intr1.clkout2 */
- ;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins =
- /* Slave 1 */
- 0x110 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxerr.mii1_rxerr */
- 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txen.mii1_txen */
- 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxdv.mii1_rxdv */
- 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd3.mii1_txd3 */
- 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd2.mii1_txd2 */
- 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd1.mii1_txd1 */
- 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd0.mii1_txd0 */
- 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_txclk.mii1_txclk */
- 0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxclk.mii1_rxclk */
- 0x134 (PIN_INPUT_PULLUP
Re: [PATCH] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
Op 6 sep. 2013, om 09:10 heeft Koen Kooi k...@dominion.thruhere.net het
volgende geschreven:
Op 6 sep. 2013, om 08:57 heeft George Cherian george.cher...@ti.com het
volgende geschreven:
On 9/6/2013 12:03 PM, Koen Kooi wrote:
The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI
added,
so create a common dtsi both can use. MMC support for AM335x still isn't
in, so
only the LDO change has been added.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
.../{am335x-bone.dts = am335x-bone-common.dtsi} | 3 -
arch/arm/boot/dts/am335x-bone.dts | 256
+
arch/arm/boot/dts/am335x-boneblack.dts | 18 ++
3 files changed, 19 insertions(+), 258 deletions(-)
copy arch/arm/boot/dts/{am335x-bone.dts = am335x-bone-common.dtsi} (99%)
create mode 100644 arch/arm/boot/dts/am335x-boneblack.dts
How did you test am335x-boneblack.dtb? where are the Makefile changes for
boneblack?
Ah, I missed the makefile in my commit. I have a bunch of other patches on
top to make more stuff work.
[..]
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2012 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.
+ */
+/dts-v1/;
+
+#include am33xx.dtsi
Why cant we add am33xx.dtsi in am335x-bone-common.dtsi ?
That didn't work when I tried it. It did work before the preprocessor changes
when using /include/
+#include am335x-bone-common.dtsi
+
+ldo3_reg {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+};
+
With this ldo values mmc was not working for me on Boneblack.
got it working with
ldo3_reg {
regulator-min-microvolt = 180;
regulator-max-microvolt = 330;
regulator-always-on;
};
That LDO is shared, the other consumer will get fried if you use 3.3V. I
forget if it's DDR3 or HDMI.
On the black the LDOs changed, so for mmc (which (*$)@()$@) still isn't in
mainline) you need:
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index e76d575..ae90a30 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -362,6 +362,13 @@
regulator-always-on;
};
};
+
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index b4237fc..e092a61 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -16,7 +16,12 @@
regulator-always-on;
};
-mmc2 {
+mmc1 {
+ vmmc-supply = vmmcsd_fixed;
+};
+
+mmc2 {
+ vmmc-supply = vmmcsd_fixed;
pinctrl-names = default;
pinctrl-0 = emmc_pins;
vmmc-supply = ldo3_reg;
--
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: OMAP2+: am335x-bone*: add DT for BeagleBone Black
Op 6 sep. 2013, om 10:51 heeft Koen Kooi k...@dominion.thruhere.net het
volgende geschreven:
Op 6 sep. 2013, om 09:10 heeft Koen Kooi k...@dominion.thruhere.net het
volgende geschreven:
Op 6 sep. 2013, om 08:57 heeft George Cherian george.cher...@ti.com het
volgende geschreven:
On 9/6/2013 12:03 PM, Koen Kooi wrote:
The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI
added,
so create a common dtsi both can use. MMC support for AM335x still isn't
in, so
only the LDO change has been added.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
.../{am335x-bone.dts = am335x-bone-common.dtsi} | 3 -
arch/arm/boot/dts/am335x-bone.dts | 256
+
arch/arm/boot/dts/am335x-boneblack.dts | 18 ++
3 files changed, 19 insertions(+), 258 deletions(-)
copy arch/arm/boot/dts/{am335x-bone.dts = am335x-bone-common.dtsi} (99%)
create mode 100644 arch/arm/boot/dts/am335x-boneblack.dts
How did you test am335x-boneblack.dtb? where are the Makefile changes for
boneblack?
Ah, I missed the makefile in my commit. I have a bunch of other patches on
top to make more stuff work.
[..]
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2012 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.
+ */
+/dts-v1/;
+
+#include am33xx.dtsi
Why cant we add am33xx.dtsi in am335x-bone-common.dtsi ?
That didn't work when I tried it. It did work before the preprocessor
changes when using /include/
+#include am335x-bone-common.dtsi
+
+ldo3_reg {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+};
+
With this ldo values mmc was not working for me on Boneblack.
got it working with
ldo3_reg {
regulator-min-microvolt = 180;
regulator-max-microvolt = 330;
regulator-always-on;
};
That LDO is shared, the other consumer will get fried if you use 3.3V. I
forget if it's DDR3 or HDMI.
On the black the LDOs changed, so for mmc (which (*$)@()$@) still isn't in
mainline) you need:
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index e76d575..ae90a30 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -362,6 +362,13 @@
regulator-always-on;
};
};
+
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index b4237fc..e092a61 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -16,7 +16,12 @@
regulator-always-on;
};
-mmc2 {
+mmc1 {
+ vmmc-supply = vmmcsd_fixed;
+};
+
+mmc2 {
+ vmmc-supply = vmmcsd_fixed;
pinctrl-names = default;
pinctrl-0 = emmc_pins;
vmmc-supply = ldo3_reg;
And links to all the patches:
Card-detect fix:
https://github.com/koenkooi/linux/commit/c3c87f330812275ce6aa791e2a81f4c124fe981b
Add eMMC DT node:
https://github.com/koenkooi/linux/commit/22459b61a7e80e05ab1cd02b9ec0a4467bf9fa4b
Fix mmc regulator:
https://github.com/koenkooi/linux/commit/8007217893b7d809782e08fa1f0d56b1083ec00d
As soon as TI gets their act together and the EDMA/MMC patchset is in Linus'
tree I'll rebase and submit the above properly.
regards,
Koen--
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: [PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
Op 8 jul. 2013, om 14:42 heeft Mark Jackson mpfj-l...@newflow.co.uk het volgende geschreven: On 18/01/13 05:14, Mugunthan V N wrote: On 1/18/2013 3:48 AM, Peter Korsgaard wrote: When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot mode in U-Boot), nothing updates the ethernet hwaddr specified for the CPSW slaves, causing the driver to use a random hwaddr, which is some times troublesome. The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes more sense to default to these rather than random ones. Add a fixup step which adds mac-address dt properties using the efuse addresses if the DTB didn't contain valid ones. Signed-off-by: Peter Korsgaard jac...@sunsite.dk This implementation looks fine. Acked-by: Mugunthan V N mugunthan...@ti.com Tested-by: Mark Jackson mpfj-l...@newflow.co.uk Tested-by: Koen Kooi k...@dominion.thruhere.net -- 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/3] ARM: OMAP2+: Legacy support for wl12xx when booted with devicetree
Op 26 apr. 2013, om 05:52 heeft Tony Lindgren t...@atomide.com het volgende geschreven: Without WLAN we cannot switch omap4 to use device tree only booting. This patch can be reverted when the binding for wl12xx is added. How much boards am I allowed to add to this? I need to get the wl12xx wifi expansionboards for beagleboard, beagleboard xM and beaglebone working with DT :) regards, Koen-- 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 0/5] usb: musb: am335x support
Op 3 apr. 2013, om 15:09 heeft Felipe Balbi ba...@ti.com het volgende geschreven: Hi, On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote: On 03.04.2013 14:04, Felipe Balbi wrote: On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote: Felipe, could you explain the background on how the dsps driver is supposed to work in host mode at boot time with the rework of the driver you did for 3.7? It might just be me not understanding the rationale behind all these changes, but appearantly, I'm not the only one who's affected by that. right, so the idea with that was to drop the huge amount of ifdeferry hack from the MUSB driver. It would be great if someone would send *CLEAN* patches adding Kconfig-based role choices again. Are Kconfig-based rules really what we want here after all? Wouldn't run-time configured settings make much more sense, considering that we need both. Say that you want to build a product with MUSB hardwired as host, why would you enable gadget framework ? I can think of at least am335x where this would be perfectly plausible (no EHCI available, only MUSB). Nice that you mention am335x, since the beaglebone has 2 MUSB controllers: one hardwired as host and one hardwired as slave. So how will KConfig options solve that?-- 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: Excessive ethernet interrupts on AM335x board
Op 12 mrt. 2013, om 16:35 heeft Mark Jackson mpfj-l...@mimc.co.uk het volgende geschreven: I'm just fighting an issue with ethernet on our custom AM335x board:- # uname -a Linux nanobone 3.9.0-rc2-00113-gd60f039 #139 Tue Mar 12 15:14:01 GMT 2013 armv7l GNU/Linux Every now and then, the whole unit slows to a crawl. The only indication of any problem is:- (a) the serial tty port becomes much less responsive (b) normal ping times jump from 1ms to 10sec (sometimes 20sec !!) (c) the ethernet interrupt count rockets (see below) You probably have PG2.x silicon, have a look at this patch: https://github.com/beagleboard/kernel/blob/3.8/patches/net/0003-cpsw-Fix-interrupt-storm-among-other-things.patch I saw some patches going into net-next today that might address this in a different way, but I haven't tried 3.9rc on an am335x 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 0/5] usb: musb: am335x support
On Fri, 2013-03-01 at 22:57 +0100, Daniel Mack wrote:
Hi Afzal, everyone,
On 03.11.2012 08:33, Mohammed, Afzal wrote:
* Daniel Mack, November 03, 2012 1:06 AM:
I'm testing these patches with an AM33xx board that has the first musb
port wired to an USB type A plug, but it doesn't yet work for me.
So there is no host interface registered. I'm unsure on how to fix this,
and I didn't get an answer yet to that question when I asked Felipe
about how interface drivers like dsps are supposed to act in order to
get host mode back after the recent musb cleanups.
What type of hardware do you test this with? Does host mode work for you?
To add to those details mentioned by Ravi,
This was tested on Beagle Bone with USB0 as usb-ethernet.
For purely Kernel part, this series is sufficient (along with
dependency mentioned in cover letter), considering
the fact that dt node is strictly not a part of Kernel.
To test this series, node for usbss should be present in dt.
Example in dt documentation can be pasted onto dtsi file
to get USB0 working.
I have to pick up this old thread because I'm still having trouble
understanding how the AM335x musb driver is meant to be used as HCD.
I used to have it working based on 3.7 with a terrible hack that reverts
a couple of old commits partly. Now I started over with a fresh setup
based on Linus' current soon-to-be 3.9-rc tip, actually hoping that the
issues are solved.
On my board, the USB is purely used as host interface, with a type B
plug soldered. In the DT, I'm using the following sniplet in accordance
to the documentation of the bindings:
usb_otg_hs: usb@4740 {
compatible = ti,musb-am33xx;
reg = 0x4740 0x1000/* usbss */
0x47401000 0x800 /* musb instance 0 */
0x47401800 0x800; /* musb instance 1 */
interrupt-parent = intc;
interrupts = 17/* usbss */
18/* musb instance 0 */
19; /* musb instance 1 */
multipoint = 1;
num-eps = 16;
ram-bits = 12;
port0-mode = 3;
port1-mode = 3;
power = 250;
ti,hwmods = usb_otg_hs;
};
The relevant config options are
CONFIG_USB_MUSB_HDRC=y
# CONFIG_USB_MUSB_TUSB6010 is not set
# CONFIG_USB_MUSB_OMAP2PLUS is not set
# CONFIG_USB_MUSB_AM35X is not set
CONFIG_USB_MUSB_DSPS=y
CONFIG_MUSB_PIO_ONLY=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_DEBUG=y
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_GADGET_DEBUG_FS=y
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
CONFIG_USB_GADGET_MUSB_HDRC=y
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_MIDI_GADGET is not set
CONFIG_USB_ZERO=m
At boot time, I only see the following message:
[1.534776] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
And when g_zero.ko is loaded, I get:
[ 12.137023] udc musb-hdrc.0.auto: registering UDC driver [zero]
[ 12.196906] gadget: adding 'source/sink'/cec4e840 to config
'source/sink'/bf00d544
[ 12.205800] gadget: dual speed source/sink: IN/ep1in, OUT/ep1out,
ISO-IN/ep13, ISO-OUT/ep14
[ 12.215862] gadget: adding 'loopback'/cec4e7c0 to config
'loopback'/bf00d5b8
[ 12.224321] gadget: dual speed loopback: IN/ep1in, OUT/ep1out
[ 12.231323] gadget: Gadget Zero, version: Cinco de Mayo 2008
[ 12.238164] gadget: zero ready
[ 12.242250] musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
[ 12.249111] musb-hdrc musb-hdrc.0.auto: new USB bus registered,
assigned bus number 1
[ 12.258151] musb-hdrc musb-hdrc.0.auto: supports USB remote wakeup
[ 12.265507] usb usb1: default language 0x0409
[ 12.271007] usb usb1: udev 1, busnum 1, minor = 0
[ 12.276699] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 12.284632] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 12.292992] usb usb1: Product: MUSB HDRC host driver
[ 12.298959] usb usb1: Manufacturer: Linux 3.8.0-10238-gbfbdcec-dirty
musb-hcd
[ 12.307166] usb usb1: SerialNumber: musb-hdrc.0.auto
[ 12.323645] usb usb1: no of_node; not parsing pinctrl DT
[ 12.330172] usb usb1: usb_probe_device
[ 12.335181] usb usb1: configuration #1 chosen from 1 choice
[ 12.342090] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[ 12.355237] hub 1-0:1.0: no of_node; not parsing pinctrl DT
[ 12.361988] hub 1-0:1.0: usb_probe_interface
[ 12.367497] hub 1-0:1.0: usb_probe_interface - got id
[ 12.373774] hub 1-0:1.0: USB hub found
[ 12.378631] hub 1-0:1.0: 1 port detected
[ 12.383515] hub 1-0:1.0: standalone hub
[ 12.388330] hub 1-0:1.0: individual port power switching
[ 12.394599] hub 1-0:1.0: no over-current protection
[ 12.400497] hub 1-0:1.0: Single TT
[
Re: [PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support
Op 24 jan. 2013, om 04:45 heeft Patil, Rachna rac...@ti.com het volgende
geschreven:
From: Patil, Rachna rac...@ti.com
Make changes to add DT support in the MFD core driver.
Signed-off-by: Patil, Rachna rac...@ti.com
---
Changes in v4:
Non-standard properties prefixed with vendor name.
drivers/mfd/ti_am335x_tscadc.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index e9f3fb5..87b446b 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -22,6 +22,8 @@
#include linux/regmap.h
#include linux/mfd/core.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/mfd/ti_am335x_tscadc.h
#include linux/input/ti_am335x_tsc.h
@@ -64,20 +66,31 @@ staticint ti_tscadc_probe(struct platform_device
*pdev)
struct resource *res;
struct clk *clk;
struct mfd_tscadc_board *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
struct mfd_cell *cell;
int err, ctrl;
int clk_value, clock_rate;
- int tsc_wires, adc_channels = 0, total_channels;
+ int tsc_wires = 0, adc_channels = 0, total_channels;
- if (!pdata) {
+ if (!pdata !pdev-dev.of_node) {
dev_err(pdev-dev, Could not find platform data\n);
return -EINVAL;
}
- if (pdata-adc_init)
- adc_channels = pdata-adc_init-adc_channels;
+ if (pdev-dev.platform_data) {
+ if (pdata-tsc_init)
+ tsc_wires = pdata-tsc_init-wires;
+
+ if (pdata-adc_init)
+ adc_channels = pdata-adc_init-adc_channels;
+ } else {
+ node = of_find_node_by_name(pdev-dev.of_node, tsc);
+ of_property_read_u32(node, ti,wires, tsc_wires);
+
+ node = of_find_node_by_name(pdev-dev.of_node, adc);
+ of_property_read_u32(node, ti,adc-channels, adc_channels);
+ }
Since AM335x is DT only, why is there a platform data codepath and why is it
the first branch it tries? And I guess the next question is related to the
first: why doesn't it work when used with DT? When I copy over the nodes from
the evm.dts to my board I get tsc tsc: Missing platform data in dmesg.
What are the chances this driver will work when applied on top of 3.8-rcX? Has
it even been tested with that? Has it been tested at all?
--
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/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
Op 30 jan. 2013, om 20:56 heeft Mugunthan V N mugunthan...@ti.com het volgende geschreven: CPDMA interrupts are not properly acknowledged which leads to interrupt storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver. Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are used for rx and tx respectively. A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly? -- 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: OMAP2: am33xx-hwmod: Fix register offset NULL check bug
Op 30 jan. 2013, om 15:39 heeft Hebbar Gururaja gururaja.heb...@ti.com het
volgende geschreven:
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
I can confirm that this fixes the crash on boot with CONFIG_RTC_DRV_OMAP=y with
3.8-rc5
regards,
Koen--
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/6] USB: Add support for multiple PHYs of same type
Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I kis...@ti.com het volgende geschreven: This patch series adds support for adding multiple PHY's (of same type). The binding information has to be present in the PHY library (otg.c) in order for it to return the appropriate PHY whenever the USB controller request for the PHY. So added a new API usb_bind_phy() to pass the binding information. This API should be called by platform specific initialization code. So the binding should be done something like usb_bind_phy(musb-hdrc.0.auto, 0, omap-usb2.1.auto); specifying the USB controller device name, index, and the PHY device name. I have done this binding for OMAP platforms, but it should be done for all the platforms. After this design, the phy can be got by passing the USB controller device pointer and the index. Developed this patch series on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv after applying usb: musb: add driver for control module patch series and ARM: dts: omap: add dt data for MUSB Did basic enumeration testing in omap4 panda and omap3 beagle. With this patchset USB completely breaks on am33xx beaglebone, is that intended? -- 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/6] USB: Add support for multiple PHYs of same type
Op 22 jan. 2013, om 17:16 heeft kishon kis...@ti.com het volgende geschreven: Hi, On Tuesday 22 January 2013 09:15 PM, kishon wrote: On Tuesday 22 January 2013 09:11 PM, Koen Kooi wrote: Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I kis...@ti.com het volgende geschreven: This patch series adds support for adding multiple PHY's (of same type). The binding information has to be present in the PHY library (otg.c) in order for it to return the appropriate PHY whenever the USB controller request for the PHY. So added a new API usb_bind_phy() to pass the binding information. This API should be called by platform specific initialization code. So the binding should be done something like usb_bind_phy(musb-hdrc.0.auto, 0, omap-usb2.1.auto); specifying the USB controller device name, index, and the PHY device name. I have done this binding for OMAP platforms, but it should be done for all the platforms. After this design, the phy can be got by passing the USB controller device pointer and the index. Developed this patch series on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv after applying usb: musb: add driver for control module patch series and ARM: dts: omap: add dt data for MUSB Did basic enumeration testing in omap4 panda and omap3 beagle. With this patchset USB completely breaks on am33xx beaglebone, is that intended? Not really. Does am33xx makes use of omap2430.c? Which PHY does am33xx uses? I figured out it uses drivers/usb/musb/musb_dsps.c (So it doesn't use omap2430.c). I think it uses TWL4030_USB (TPS659x0) as PHY. Actually it uses nop-phy as a phy, which is missing from arch/arm/boot/dts/am33xx.dtsi, so mainline is already broken. But adding the nop-phy to the DT is easy enough to patch in locally. regards, Koen-- 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 00/12] video: da8xx-fb: am335x DT support
Op 22 jan. 2013, om 17:51 heeft Afzal Mohammed af...@ti.com het volgende geschreven: Hi, This series adds DT support to da8xx-fb driver (device found on DaVinci and AM335x SoC's). It does certain cleanup's in the process. This series as compared to previous version handles configuration of the LCDC clock rate by modelling as a clock divider of CCF. This would take effect only if CCF is selected, if not, no change to existing method. This makes use of Steffen Trumtrar's v16 of display timing DT support. Wouldn't it be better to delete da8xx-fb.* and switch to Rob Clarks DRM based driver for this IP block? regards, Koen-- 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/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
Op 22 jan. 2013, om 23:36 heeft Rob Clark robdcl...@gmail.com het volgende geschreven: A simple DRM/KMS driver for the TI LCD Controller found in various smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the CMA helpers. Currently only the TFP410 DVI encoder is supported (tested with beaglebone + DVI cape). There are also various LCD displays, for which support can be added (as I get hw to test on), and an external i2c HDMI encoder found on some boards. The display controller supports a single CRTC. And the encoder+ connector are split out into sub-devices. Depending on which LCD or external encoder is actually present, the appropriate output module(s) will be loaded. v1: original v2: fix fb refcnting and few other cleanups v3: get +/- vsync/hsync from timings rather than panel-info, add option DT max-bandwidth field so driver doesn't attempt to pick a display mode with too high memory bandwidth, and other small cleanups Signed-off-by: Rob Clark robdcl...@gmail.com Tested on a beaglebone and beaglebone-black: Tested-by: Koen Kooi k...@dominion.thruhere.net-- 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/4] drm/i2c: nxp-tda998x (v2)
Op 22 jan. 2013, om 23:36 heeft Rob Clark robdcl...@gmail.com het volgende geschreven: Driver for the NXP TDA998X i2c hdmi encoder slave. v1: original v2: fix npix/nline programming Signed-off-by: Rob Clark robdcl...@gmail.com Tested on a beaglebone-black: Tested-by: Koen Kooi k...@dominion.thruhere.net -- 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: cpts: Fix build error caused by include of plat/clock.h
Op 14 dec. 2012, om 08:13 heeft Richard Cochran richardcoch...@gmail.com het volgende geschreven: On Thu, Dec 13, 2012 at 01:36:41PM -0800, Tony Lindgren wrote: Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock) mistakenly included plat/clock.h that should not be included by drivers even if it exists. Hasn't this already been fixed? https://patchwork.kernel.org/patch/1810481/ http://www.spinics.net/lists/linux-omap/msg83132.html That patch didn't get applied, so it's still broken in Linus' tree :( regards, Koen-- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Op 10 nov. 2012, om 00:40 heeft Grant Likely grant.lik...@secretlab.ca het volgende geschreven: On Fri, Nov 9, 2012 at 11:23 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/09/2012 09:28 AM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: ... I do rather suspect this use-case is quite common. NVIDIA certainly has a bunch of development boards with pluggable PMIC/audio/WiFi/display/..., and I believe there's some ability to re-use the pluggable components with a variety of base-boards. Given people within NVIDIA started talking about this recently, I asked them to enumerate all the boards we have that support pluggable components, and how common it is that some boards support being plugged into different main boards. I don't know when that enumeration will complete (or even start) but hopefully I can provide some feedback on how common the use-case is for us once it's done. From your perspective, is it important to use the exact same .dtb overlays for those add-on boards, or is it okay to have a separate build of the overlay for each base tree? I certainly think it'd be extremely beneficial to use the exact same child board .dtb with arbitrary base boards. Consider something like the Arduino shield connector format, which I /believe/ has been re-used across a wide variety of Arduino boards and other compatible or imitation boards. Now consider a vendor of an Arduino shield. The shield vendor probably wants to publish a single .dtb file that works for users irrespective of which board they're using it with. (Well, I'm not sure that Arduino can run Linux; perhaps that's why you picked BeagleBone capes for your document!) Correct, the Arduino is only an AVR with a tiny amount of ram. No Linux there. However, Arduino shields are a good example of a use case. I think there are even some Arduino shield compatible Linux boards out there. A good example of those would be the Rascal Micro: http://rascalmicro.com/ regards, Koen-- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Op 5 nov. 2012, om 21:40 heeft Grant Likely grant.lik...@secretlab.ca het volgende geschreven: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Device Tree Overlay Feature Purpose === Sometimes it is not convenient to describe an entire system with a single FDT. For example, processor modules that are plugged into one or more modules (a la the BeagleBone), or systems with an FPGA peripheral that is programmed after the system is booted. For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at runtime by loading additional overlay FDTs that amend the original data. User Stories Note - These are potential use cases, but just because it is listed here doesn't mean it is important. I just want to thoroughly think through the implications before making design decisions. I think the beaglebone use cases cover it as well, but it deserves a seperate mention: SOMs. Gumstix is a good example of those, their website has a list of the different expansionboards they sell so we can see if we missed a use case somewhere. Their expansionboards have an EEPROM to ID them, just like the beagleboard classic/xM expansionboards, but I don't know if all 3rd party vendors honour that standard. I know the Ettus USRP E-100 on my desk has it. regards, Koen-- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Op 7 nov. 2012, om 23:35 heeft Ryan Mallon rmal...@gmail.com het volgende geschreven: On 06/11/12 08:40, Tabi Timur-B04825 wrote: On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. What's wrong with having the boot loader detect the presence of the Cape and update the device tree accordingly? We do this all the time in U-Boot. Doing stuff like reading EEPROMs and testing for the presence of hardware is easier in U-Boot than in Linux. This is probably okay for some hardware, but doesn't work in the general case. Not all hardware is detectable, for example a cape which just adds a set of LEDs for GPIO pins. Also, some hardware might not easily be detectable without adding additional complexity to the boot loader. And as Pantelis mentioned before, I really don't want my users to change the bootloader whenever they add a new LED. Touching the bootloader is just too accident prone, we had a ton of RMA requests for older versions of the beagleboard from people trying to upgrade u-boot. Apart from the above I'd like to have fewer points of failure. Right now I need to keep uImage and foo.dtb in sync and I hate to add u-boot to that equasion as well. regards, Koen-- 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 0/3] capebus moving omap_devices to mach-omap2
Op 2 nov. 2012, om 10:26 heeft Cousson, Benoit b-cous...@ti.com het
volgende geschreven:
Hi Jason,
On 11/1/2012 7:50 PM, Jason Kridner wrote:
My apologies for starting a new thread, but I don't have this thread
in my Inbox.
http://www.spinics.net/lists/linux-omap/msg81034.html
Tony Lindgren wrote:
* Pantelis Antoniou panto@xxx [121031 15:02]:
So when device's node is 'disabled' of_platform_device_create_pdata()
will not create the device.
Now, of course it is possible to re-trigger the platform's probe method
to be called, and in fact I do so in the capebus patches.
You should fix this in generic way then rather than working
around it in capebus. The same problem exists changing
between different functionality for the shared pins,
let's say between USB pins and UART pins if you want a
serial debug console on some phone.
The current capebus solution goes a long way to fixing a huge issue
for BeagleBone users and I don't understand what seems to be a
push-back on principle. On BeagleBone capes, these conflicts cannot be
resolved early.
I don't think there is any push-back on the principle. It is a very valid
problem that does not have any solution today.
The comments are more on the implementation.
Do you have suggestions on some more generic method? It seems to me
the proposed capebus approach strikes a good balance.
Well, yeah, that's a generic DT issue, not a beagle-cape issue.
We should not necessarily handle it by introducing some fake bus and some new
binding like spi-dt / i2c-dt that does not mean anything in term of HW.
DT is about pure HW representation. Introducing some fake hierarchy to make
SW life easier is not necessarily the good approach.
I see, pure HW. Let's look at this:
gpio_keys {
compatible = gpio-keys;
pinctrl-names = default;
pinctrl-0 = bone_lcd3_cape_keys_00A0_pins;
#address-cells = 1;
#size-cells = 0;
button@1 {
debounce_interval = 50;
linux,code = 105;
label = left;
gpios = gpio2 16 0x0;
gpio-key,wakeup;
autorepeat;
};
Is the linux,code pure hardware or have there already been exceptions to that
rule?
regards,
Koen--
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 0/3] capebus moving omap_devices to mach-omap2
Op 2 nov. 2012, om 10:42 heeft Russ Dill russ.d...@ti.com het volgende geschreven: On Fri, Nov 2, 2012 at 1:57 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Thu, Nov 01, 2012 at 04:49:23PM -0700, Russ Dill wrote: On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi ba...@ti.com wrote: HI, On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote: Hi Alan, On Nov 1, 2012, at 3:51 PM, Alan Cox wrote: What they want, and what every user wants, is I plug this board in, and the driver make sure everything is loaded and ready. No, the end users don't want to see any of the implementation details of how the bitfile is transported; the driver can handle it. That doesn't necessarily make it a bus merely some kind of hotplug enumeration of devices. That should all work properly both for devices and busses with spi and i²c as the final bits needed for it got fixed some time ago. In an ideal world you don't want to be writing custom drivers for stuff. If your cape routes an i²c serial device to the existing system i²c busses then you want to just create an instance of any existing driver on the existing i²c bus not create a whole new layer of goop. It does need to do the plumbing and resource management for the plumbing but thats not the same as being a bus. Alan Fair enough. But there's no such thing a 'hotplug enumeration construct' in Linux yet, and a bus is the closest thing to it. It does take advantage of the nice way device code matches drivers and devices though. I'm afraid that having the I2C/SPI drivers doing the detection won't work. The capes can have arbitrary I2C/SPI devices (and even more weird components). There is no way to assure for example that the I2C device responding to address 'foo' in cape A is the same I2C device responding to the same address in cape B. your -detect() method should take care of that. There isn't some magical serial number in I²C devices that a -detect() method can read and the implementation of I²C is somewhat flexible. One devices read may be another devices write. A detect look at what other drivers do. You can read a revision register, you can write a command and see if the device responds as expected, it doesn't matter. Since a revision register isn't required by the I²C spec, it isn't implemented on a huge number of chips. Also, having a few dozen probe routines come though and write to random address of every single I²C device can a) take a really long time, and b) have quite a few unintended side effects. method that only performs reads could easily toggle a gpio that resets the board, rewrite and eeprom, or set the printer on fire. If you how ? It's just a read. Because the I²C spec is incredibly flexible. For a lot of devices, reading from a register is done by writing the register address, and then reading the contents. For devices that don't implement registers in that way (such as many eeproms), this is just a write. browse through various detect functions, yes, some of them key off an ID, but a lot of them just check various registers to see if certain bits are zero, or certain bits are one. A lot of I²C devices I've dealt with have no good way of probing them, especially GPIO chips (you'll notice none of the I²C GPIO expanders have detect functions) it doesn't mean it can't be done. Really? Please, do tell how you would write a detect function for a PCA9534. It has 4 registers, an input port registers, an output port register, a polarity inversion register, and a configuration register. And don't forget, since we are probing, every detect routine for every I²C driver will have to run with every I²C address on every bus, possibly with both address formats. Worse, things like early revisions of the picoDLP projector will erase their firmware if you do a linear scan through all addresses. regards, Koen-- 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 0/3] capebus moving omap_devices to mach-omap2
tl;dr: please suggest an actual solution that allows plugplay when plugging in multiple capes and applying power after that. Preferably one that doesn't pass the buck to u-boot. Op 1 nov. 2012, om 12:26 heeft Cousson, Benoit b-cous...@ti.com het volgende geschreven: Hi Panto, On 11/1/2012 11:39 AM, Pantelis Antoniou wrote: Hi Benoit, On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote: On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = disabled for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Op 1 nov. 2012, om 14:06 heeft Felipe Balbi ba...@ti.com het volgende geschreven: Hi, On Thu, Nov 01, 2012 at 01:00:21PM +0100, Koen Kooi wrote: tl;dr: please suggest an actual solution that allows plugplay when plugging in multiple capes and applying power after that. Preferably one that doesn't pass the buck to u-boot. I can think of a few ways: 1) ship your distribution with all necessary drivers and let udev handle driver probing. clearly this will require constant updates for the distribution as new capes are developed. But IIUC, that's the same with Arduino where new libraries are added to the Arduino OS. And how are you going to handle pinmuxing and conflict resolution? You're basically saying that people should just use /dev/mem to write drivers, since you don't consider their use case valid. 2) ship with drivers for EEPROMs only and setup a repository of drivers this would require every driver to be packaged separately, then you create a setup where bone's userland will use EEPROMs data to figure out which drivers it needs, pass that information to SDK via USB, then SDK downloads all necessary/missing packages, sends them to bone via USB and all packages are installed on the bone. Note that since packages would be 'installed', this would be a one-time-only thing. I lack the words to describe my emotions after reading this. Let's leave it at that. 3) realize that if your user can build an FPGA cape, s/he can most likely write code and adding/recompiling kernel shouldn't be the biggest of his/her worries (no comments to this one, I understand it's not feasible) You'd be surprised. in any case, capebus sounds like something which is hugely unnecessary. On tablets and phones, yes. But TI chips are use for different use-cases, bone + capes being one of those. ps: at least for the I2C subsystem, i2c-core can detect for you if your driver provides -detect() method. So I just need to patch all i2c drivers and force people to use the standard address for the i2c chip when designing a board. Op 1 nov. 2012, om 12:26 heeft Cousson, Benoit b-cous...@ti.com het volgende geschreven: FWIW, we do have a similar, but simpler, problem with the beagle / beagle-xm and panda / panda-es. But for the moment we are just using a different DTS for each board. A different DTS for each board combination... There alot more capes for the bone that they are for the beagle the panda. And more are going to come, but not necessarily from people that have any connection to TI or CCO. Sure, but my point is that your solution will not solve our problem :-) This is a generic problem that you address with a very custom / specific approach. You still haven't described how I could solve the issue of conflicting capes using a single DTS. Well I don't have the solution otherwise I will have done it already :-) My point is that the solution has to be in the DT core if not in the bootloader. snarky commentSo when we at beagleboard.org handled the beagleboard and beagleboard xM expansionboards in the bootloader (detection, muxing, etc) we were told it was wrong and we should handle it in the kernel and if we waited a bit, DT would solve everything. And now that we actually handle it in the kernel you are saying that it is wrong and we should handle it in the bootloader and that DT won't solve everything. I guess someone will now tell us that uEFI will fix everything./snarky comment Apart from that, you and others still fail to tell us how you want to handle a user (or customer) that buys a beaglebone, an LCD cape, a weatherstation cape and a geiger counter cape and plugs those together and powers them on. With the evil TI vendor tree and extra patches the boardfile reads the eeproms and tries its best to instantiate all the platform data. One of the capes won't have working LEDs since appending to the leds-gpio struct is pretty much impossible in this couldn't you just instantiate multiple leds-gpio device ? No, and that is a problem in the driver core, see earlier discussions about similar problems. situation. But it gets a picture on the screen, blinks LEDs and does largely what the user expects. With capebus we get: 1) da8xx-fb which lacks DT bindingsp[1] receives plaftorm data to match the LCD this is something which could be fixed at the driver level, right ? :-) You'd have to tell your coworkers that. 2) the i2c sensors on the weathercape are registered that will work with or without capebus. Not in a plug and play way. 3) the one-wire bus on the weathercape gets registered also should work with or without capebus. Not in a plug and play way. 4) the LEDs on the lcd cape get registered5 also works with or without capebus. Not in a plug and play way. 5) the LED on the geigercape gets registered and adds
Re: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
Op 18 okt. 2012, om 05:06 heeft Richard Cochran richardcoch...@gmail.com het volgende geschreven: On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [121017 16:39]: Hi Richard On Wed, 17 Oct 2012, Richard Cochran wrote: Would you please take this bugfix for 3.7-rc2? The suggestion to mail you came from Toni Lindgren. The context where it came from is here: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html This patch appears to add a new feature, correct? I don't think the CPSW could have worked in the past without this data present. So it looks to me like this is 3.8 material, unless Tony would like it to go in sooner? Yeah unless it fixes something, we should just queue it for v3.8 merge window. So there has been this cpsw driver since v3.4-rc1~177^2~5 df82859 netdev: driver: ethernet: Add TI CPSW driver and four people signed off on it, so it must have been working at one point. Since the device tree make-over, the driver is a derelict, and thus the present patch is fixing a regression. Have a look at the tscadc driver for am335x that has had a few rounds of review. That one lacks DT bindings, so it can't be tested on this DT only platform. That a driver has been accepted in mainline does not mean it works, for am335x it just means that it compiles. The patches I needed to get cpsw to work on beaglebone: https://github.com/beagleboard/kernel/tree/3.7/patches/cpsw regards, Koen-- 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
Multimachine uImage and cpufreq-cpu0/cpufreq-omap2 breakage
Hi, I'm currently building 3.7rc1 kernels meant to run on beagleboards (omap3), pandaboards (omap4) and beaglebones (am335x). At the moment I'm only testing it on beaglebone and I noticed a problem with the different cpufreq drivers getting in eachothers way. I patched in cpufreq-cpu0 support for AM335x and that's was working great. After rebasing to 3.7-rc1 it stopped working because cpufreq-omap2 tried to load, failed and made the cpufreq-cpu0 driver error out. The workaround is simple: only enable on driver. So my question is: Is this the intended behaviour? I would expect the cpufreq-omap2 driver to not load when booted on am335x using DT, but it is a persistent bugger. Thanks, Koen-- 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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
Op 26 sep. 2012, om 13:37 heeft Hebbar, Gururaja gururaja.heb...@ti.com het volgende geschreven: On Wed, Sep 12, 2012 at 17:32:38, Hebbar, Gururaja wrote: On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote: On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: HSMMC IP on AM33xx need a special setting to handle High-speed cards. Other platforms like TI81xx, OMAP4 may need this as-well. This depends on the HSMMC IP timing closure done for the high speed cards. From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation) The MMC/SD/SDIO output signals can be driven on either falling edge or rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows to reach better timing performance, and thus to increase data transfer frequency. There are few pre-requisites for enabling the HSPE bit - Controller should support High-Speed-Enable Bit and - Controller should not be using DDR Mode and - Controller should advertise that it supports High Speed in capabilities register and - MMC/SD clock coming out of controller 25MHz The patch is well written. But then, I don't see a need for a DT binding for this feature. My reasons for DT Binding 1. Not all platforms using this driver has this bit (OMAP2) 2. Not all platforms using this driver needs this bit to be enabled (OMAP4) 3. Platforms which require this bit this to be set needs a method to inform driver. In order to not disturb old/unsupported platforms, I chose this DT method. By definition, HS implies 25MHz or above, so that check seems to be redundant as well. There are chances that the platform Max Clock output from HSMMC IP is than 25 MHz even if the card is High Speed. In such cases it would be better to Confirm that the Clock output is actually 25 MHz Kindly correct me if I am wrong. Meanwhile, I'll check with HSPE enabled on OMAP. Gentle Ping. Matt Poter recently submitted EDMA related patches as RFC. He confirmed that basic mmc is working on AM335x with his edma patches. Above patch is required to get High-speed cards working on AM335x. I haven't seen any review comments for this. Can this be pulled in for 3.7? I had trouble applying this to 3.6-rc7, is that a known problem and should I try linux-next? regards, Koen-- 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
replacement for /sys/kernel/debug/omap_mux in DT/pinctrl land ?
Hi, With a patched 3.6rc7 on my beaglebone I can set the pinmux for pins using pinctrl and that seems to work. On the 3.2 vendor tree there was the omap_mux driver with an awesome debugfs interface: # cat /sys/kernel/debug/omap_mux/lcd_data0 name: lcd_data0.ehrpwm2A (0x44e108a0/0x8a0 = 0x0003), b NA, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE3 signals: lcd_data0 | gpmc_a0 | pr1_mii_mt0_clk | ehrpwm2A | NA | pr1_pru1_pru_r30_0 | pr1_pru1_pru_r31_0 | gpio2_6 Notice how it tells me that it's muxed the PWM in 2 ways: signal name (ehrpwm2A) and register content (0x0003). Compare to pinctrl: root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 * pinconf-pins:pin 40 (44e108a0): pingroups:pin 40 (44e108a0) pinmux-pins:pin 40 (44e108a0): 4a30.pruss (GPIO UNCLAIMED) function pinmux_pruss_led_pins group pinmux_pruss_led_pins pins:pin 40 (44e108a0) pinctrl-single What is that pin muxed to? It is part of the 'pinmux_pruss_led_pins' in the DT, but debugfs remains mute on how pin 40 is muxed. regards, Koen-- 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: replacement for /sys/kernel/debug/omap_mux in DT/pinctrl land ?
Op 26 sep. 2012, om 18:15 heeft Matt Porter mpor...@ti.com het volgende
geschreven:
On Wed, Sep 26, 2012 at 03:03:27PM +0200, Linus Walleij wrote:
On Wed, Sep 26, 2012 at 2:56 PM, Matt Porter mpor...@ti.com wrote:
Adding Linus W. and lkml.
On Wed, Sep 26, 2012 at 01:46:45PM +0200, Koen Kooi wrote:
Hi,
With a patched 3.6rc7 on my beaglebone I can set the pinmux for pins using
pinctrl and that seems to work. On the 3.2 vendor tree there was the
omap_mux driver with an awesome debugfs interface:
# cat /sys/kernel/debug/omap_mux/lcd_data0
name: lcd_data0.ehrpwm2A (0x44e108a0/0x8a0 = 0x0003), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE3
signals: lcd_data0 | gpmc_a0 | pr1_mii_mt0_clk | ehrpwm2A | NA |
pr1_pru1_pru_r30_0 | pr1_pru1_pru_r31_0 | gpio2_6
Notice how it tells me that it's muxed the PWM in 2 ways: signal name
(ehrpwm2A) and register content (0x0003). Compare to pinctrl:
root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 *
pinconf-pins:pin 40 (44e108a0):
pingroups:pin 40 (44e108a0)
pinmux-pins:pin 40 (44e108a0): 4a30.pruss (GPIO UNCLAIMED) function
pinmux_pruss_led_pins group pinmux_pruss_led_pins
pins:pin 40 (44e108a0) pinctrl-single
What is that pin muxed to? It is part of the 'pinmux_pruss_led_pins' in
the DT, but debugfs remains mute on how pin 40 is muxed.
It does seem like a pretty big gap in the pinctrl/pinmux debugfs
interface when viewed from an OMAP perspective. Ideally there would
be a pinctrl/pinmux hook to the pinmux driver to provide the detailed
h/w specific pin state info.
So add the hooks you need?
Ok. :)
I assume you are using Tony's pinctrl-single driver, so Tony is the one to
ask.
Yes, so roughly for pinctrl-single I have the following...likely broken
for arbitrary register sizes but a starting point. Tony, any thoughts
about this?
Koen: you just need a userspace tool that groks the raw data for human
consumption. The nice thing is that the old omap_mux implementation had
plenty of OMAP-isms in the parser that didn't apply to AM33xx. A
userspace tool can do a better job of parsing on a per-part basis.
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -246,7 +246,15 @@ static void pcs_pin_dbg_show(struct pinctrl_dev *pctldev,
struct seq_file *s,
unsigned offset)
{
- seq_printf(s, DRIVER_NAME);
+ struct pcs_device *pcs;
+ unsigned val;
+
+ pcs = pinctrl_dev_get_drvdata(pctldev);
+
+ val = pcs-read(pcs-base + offset);
+ val = pcs-fmask;
+
+ seq_printf(s, %08x %s , val, DRIVER_NAME);
}
static void pcs_dt_free_map(struct pinctrl_dev *pctldev,
Much better already:
root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 pins
pin 40 (44e108a0) 0027 pinctrl-single
Now I can write a userspace tool do list the current muxes without resorting to
devmem2!
--
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: replacement for /sys/kernel/debug/omap_mux in DT/pinctrl land ?
Op 26 sep. 2012, om 20:52 heeft Tony Lindgren t...@atomide.com het volgende
geschreven:
* Koen Kooi k...@dominion.thruhere.net [120926 10:23]:
Op 26 sep. 2012, om 18:15 heeft Matt Porter mpor...@ti.com het volgende
geschreven:
On Wed, Sep 26, 2012 at 03:03:27PM +0200, Linus Walleij wrote:
On Wed, Sep 26, 2012 at 2:56 PM, Matt Porter mpor...@ti.com wrote:
Adding Linus W. and lkml.
On Wed, Sep 26, 2012 at 01:46:45PM +0200, Koen Kooi wrote:
Hi,
With a patched 3.6rc7 on my beaglebone I can set the pinmux for pins
using pinctrl and that seems to work. On the 3.2 vendor tree there was
the omap_mux driver with an awesome debugfs interface:
# cat /sys/kernel/debug/omap_mux/lcd_data0
name: lcd_data0.ehrpwm2A (0x44e108a0/0x8a0 = 0x0003), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE3
signals: lcd_data0 | gpmc_a0 | pr1_mii_mt0_clk | ehrpwm2A | NA |
pr1_pru1_pru_r30_0 | pr1_pru1_pru_r31_0 | gpio2_6
Notice how it tells me that it's muxed the PWM in 2 ways: signal name
(ehrpwm2A) and register content (0x0003). Compare to pinctrl:
root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 *
pinconf-pins:pin 40 (44e108a0):
pingroups:pin 40 (44e108a0)
pinmux-pins:pin 40 (44e108a0): 4a30.pruss (GPIO UNCLAIMED) function
pinmux_pruss_led_pins group pinmux_pruss_led_pins
pins:pin 40 (44e108a0) pinctrl-single
What is that pin muxed to? It is part of the 'pinmux_pruss_led_pins' in
the DT, but debugfs remains mute on how pin 40 is muxed.
It does seem like a pretty big gap in the pinctrl/pinmux debugfs
interface when viewed from an OMAP perspective. Ideally there would
be a pinctrl/pinmux hook to the pinmux driver to provide the detailed
h/w specific pin state info.
So add the hooks you need?
Ok. :)
I assume you are using Tony's pinctrl-single driver, so Tony is the one to
ask.
Yes, so roughly for pinctrl-single I have the following...likely broken
for arbitrary register sizes but a starting point. Tony, any thoughts
about this?
Koen: you just need a userspace tool that groks the raw data for human
consumption. The nice thing is that the old omap_mux implementation had
plenty of OMAP-isms in the parser that didn't apply to AM33xx. A
userspace tool can do a better job of parsing on a per-part basis.
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -246,7 +246,15 @@ static void pcs_pin_dbg_show(struct pinctrl_dev
*pctldev,
struct seq_file *s,
unsigned offset)
{
- seq_printf(s, DRIVER_NAME);
+ struct pcs_device *pcs;
+ unsigned val;
+
+ pcs = pinctrl_dev_get_drvdata(pctldev);
+
+ val = pcs-read(pcs-base + offset);
+ val = pcs-fmask;
+
+ seq_printf(s, %08x %s , val, DRIVER_NAME);
}
static void pcs_dt_free_map(struct pinctrl_dev *pctldev,
Much better already:
root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 pins
pin 40 (44e108a0) 0027 pinctrl-single
Cool :) For the proper patch feel free to add:
Acked-by: Tony Lindgren t...@atomide.com
Now I can write a userspace tool do list the current muxes without resorting
to devmem2!
Yeah maybe add support to omapconf for that? I can generate
the data for balls etc from old omap mux if you let me know the
format you need.
It's for am335x :)--
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 v7 2/3] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
Op 6 sep. 2012, om 11:38 heeft AnilKumar Ch anilku...@ti.com het volgende
geschreven:
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
[k...@dominion.thruhere.net: led0, led1 suggested by koen]
Signed-off-by: AnilKumar Ch anilku...@ti.com
Acked-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone.dts | 43 +
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..b0a7409 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,11 +18,54 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ userled_pins: pinmux_userled_pins {
+ pinctrl-single,pins =
+ 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
MODE7 */
+ 0x58 0x17 /* gpmc_a6.gpio1_22,
OUTPUT_PULLUP | MODE7 */
+ 0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT |
MODE7 */
+ 0x60 0x17 /* gpmc_a8.gpio1_24,
OUTPUT_PULLUP | MODE7 */
+ ;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = okay;
};
+ leds {
+ compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 = userled_pins;
+
+ heartbeat {
+ label = beaglebone:green:usr0;
+ gpios = gpio2 21 0;
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+
+ mmc {
+ label = beaglebone:green:usr1;
+ gpios = gpio2 22 0;
+ linux,default-trigger = mmc0;
+ default-state = off;
+ };
+
+ led2 {
+ label = beaglebone:green:usr2;
+ gpios = gpio2 23 0;
+ default-state = off;
+ };
+
+ led3 {
+ label = beaglebone:green:usr3;
+ gpios = gpio2 24 0;
+ default-state = off;
+ };
+ };
+
i2c1: i2c@44e0b000 {
status = okay;
clock-frequency = 40;
--
1.7.9.5
--
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 v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Op 28 aug. 2012, om 07:34 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Fri, Aug 24, 2012 at 13:32:17, Koen Kooi wrote: Op 24 aug. 2012, om 09:56 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 24 aug. 2012, om 09:26 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote: Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? Use this repo to test on beaglebone https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl This wiki talks about how to build and use? https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree Note: Enable tps65217 regulator in kernel config. I used that repo and as a seperate test I rebased that to latest mainline, same thing: as soon as I turn on the TPS in the .config it crashes on boot. Is the pinctrl repo the *exact* repo you used to test the patches on beaglebone? I tested on latest mainline after merging to am335x-upstream-staging-pinctrl (voltage also changing) Can you share your .config and uImage? Config: https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone My config details:- (After merge) 1. omap2plus_defconfig 2. Enable tps65217 MFD driver 3. Enable tps65217 regulator driver I rebased onto latest mainline and refreshed the base patches from Vaibhav and I now get: [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1 So it boots! I don't know what made it break before, but it's working now :) *sigh* I'm an idiot: root@beaglebone:~# uname -a Linux beaglebone 3.6.0-rc3-00103-gfd02083 #86 SMP Fri Aug 24 09:45:54 CEST 2012 armv7l GNU/Linux root@beaglebone:~# zcat /proc/config.gz | grep 217 CONFIG_MFD_TPS65217=y # CONFIG_REGULATOR_TPS65217 is not set Will retry with regulator driver actually turned on in a bit. Is it working after enabling the regulator? It took me a while to get back to this problem, but it still isn't working for me. I did manage to get more info on the error: root@bone-mainline:~# insmod tps65217-regulator.ko [ 32.754419] Unable to handle kernel NULL pointer dereference at virtual address 00c8 [ 32.763087] pgd = cea6 [ 32.765969] [00c8] *pgd=8fbed831, *pte=, *ppte= [ 32.772617] Internal error: Oops: 17 [#1] SMP THUMB2 [ 32.777827] Modules linked in: tps65217_regulator(+) ip_tables x_tables snd_soc_omap snd_soc_core regmap_spi snd_pcm snd_timer snd soundcore snd_page_alloc ipv6 [ 32.792976] CPU: 0Not tainted (3.6.0-rc4 #109) [ 32.798106] PC is at regmap_read+0x8/0x38 [ 32.802315] LR is at regulator_get_voltage_sel_regmap+0x15/0x38 [ 32.808525] pc : [c0233c8c]lr : [c0208619]psr: 6033 [ 32.808525] sp : ceb2fd20 ip : fp : c0ba6168 [ 32.820565] r10: c0619fac r9 : cf926840 r8 : cf0278b0 [ 32.826045] r7 : cf92c008 r6 : cf115d40 r5 : 000e r4 : [ 32.832892] r3 : bf946440 r2 : ceb2fd34 r1 : 000e r0 : 000e [ 32.839740] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user [ 32.847406] Control: 50c5387d Table: 8ea60019 DAC: 0015 [ 32.853431] Process insmod (pid: 176, stack limit = 0xceb2e2f8) [ 32.859638] Stack: (0xceb2fd20 to 0xceb3) [ 32.864214] fd20: cf027800 bf946440 cf115d40 c0208619 0001 c00a59b1 cf027800 c0206cc3 [ 32.872796] fd40: cf027800 c0209d65 c00fefcb c0626ef0 ceb2fd7c cf027810 [ 32.881379] fd60: c00fefcb c0379721 ceb28b40 0001 c061bf74 6013 [ 32.889961] fd80: [ 32.898542] fda0: [ 32.907128] fdc0: cf072950 0044 cf92c008 c0db8fd0 [ 32.915712] fde0: bf946440 bf948001 0028 0030 03fb bf946397 cf92c008 cf926840 [ 32.924296] fe00: cf92c410 c0db8fd0 bf946768 cf92c008 [ 32.932878] fe20: c0baa0b0 c0baa0c0 bf946768 c022af2b c022af19 c022a30d cf92c008 [ 32.941460] fe40: bf946768 cf92c03c bf948001
Re: [PATCH v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Op 5 sep. 2012, om 16:24 heeft Matt Porter mpor...@ti.com het volgende geschreven: On Wed, Sep 05, 2012 at 03:29:30PM +0200, Koen Kooi wrote: Op 28 aug. 2012, om 07:34 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Fri, Aug 24, 2012 at 13:32:17, Koen Kooi wrote: Op 24 aug. 2012, om 09:56 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 24 aug. 2012, om 09:26 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote: Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? Use this repo to test on beaglebone https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl This wiki talks about how to build and use? https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree Note: Enable tps65217 regulator in kernel config. I used that repo and as a seperate test I rebased that to latest mainline, same thing: as soon as I turn on the TPS in the .config it crashes on boot. Is the pinctrl repo the *exact* repo you used to test the patches on beaglebone? I tested on latest mainline after merging to am335x-upstream-staging-pinctrl (voltage also changing) Can you share your .config and uImage? Config: https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone My config details:- (After merge) 1. omap2plus_defconfig 2. Enable tps65217 MFD driver 3. Enable tps65217 regulator driver I rebased onto latest mainline and refreshed the base patches from Vaibhav and I now get: [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1 So it boots! I don't know what made it break before, but it's working now :) *sigh* I'm an idiot: root@beaglebone:~# uname -a Linux beaglebone 3.6.0-rc3-00103-gfd02083 #86 SMP Fri Aug 24 09:45:54 CEST 2012 armv7l GNU/Linux root@beaglebone:~# zcat /proc/config.gz | grep 217 CONFIG_MFD_TPS65217=y # CONFIG_REGULATOR_TPS65217 is not set Will retry with regulator driver actually turned on in a bit. Is it working after enabling the regulator? It took me a while to get back to this problem, but it still isn't working for me. I did manage to get more info on the error: root@bone-mainline:~# insmod tps65217-regulator.ko [ 32.754419] Unable to handle kernel NULL pointer dereference at virtual address 00c8 [ 32.763087] pgd = cea6 [ 32.765969] [00c8] *pgd=8fbed831, *pte=, *ppte= [ 32.772617] Internal error: Oops: 17 [#1] SMP THUMB2 [ 32.777827] Modules linked in: tps65217_regulator(+) ip_tables x_tables snd_soc_omap snd_soc_core regmap_spi snd_pcm snd_timer snd soundcore snd_page_alloc ipv6 [ 32.792976] CPU: 0Not tainted (3.6.0-rc4 #109) [ 32.798106] PC is at regmap_read+0x8/0x38 [ 32.802315] LR is at regulator_get_voltage_sel_regmap+0x15/0x38 I just got to this same point last night as I needed this working to test omap_hsmmc with edma dmaengine... The problem is that the tps65217-regulator driver is handing the wrong device to regulator_register() and it contains a null regmap. This patch passes in the the parent dev to fix it. Maybe I missed another patch that addresses this in a different way, such as the regulator devices being stuffed with the regmap devres? -Matt From 40d118bebc5eaf2a8df4f8b5e113b892a3210f96 Mon Sep 17 00:00:00 2001 From: Matt Porter mpor...@ti.com Date: Wed, 5 Sep 2012 10:09:50 -0400 Subject: [PATCH] regulator: tps65217: fix crash during registration The struct device for each platform device bound to this driver is a child to the parent mfd device. The parent device is the one that actually contains the regmap devres so fix the null pointer dereference during the first regmap access in registration by passing in the parent device. Signed-off-by: Matt Porter mpor...@ti.com --- drivers/regulator/tps65217-regulator.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/tps65217-regulator.c b/drivers/regulator/tps65217-regulator.c index 6caa222..af4916c 100644 --- a/drivers/regulator/tps65217-regulator.c +++ b/drivers/regulator/tps65217-regulator.c
Re: [PATCH RESEND v4 2/3] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
Op 1 sep. 2012 om 09:01 heeft AnilKumar, Chimata anilku...@ti.com het
volgende geschreven:
Hi Koen,
On Fri, Aug 31, 2012 at 21:23:18, Koen Kooi wrote:
Op 30 aug. 2012, om 22:35 heeft Tony Lindgren t...@atomide.com het
volgende geschreven:
* AnilKumar Ch anilku...@ti.com [120828 01:11]:
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index a7906cb..58f5042 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,6 +18,20 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+am3358_pinmux: pinmux@44E10800 {
+pinctrl-names = default;
+pinctrl-0 = userled_pins;
+
+userled_pins: pinmux_userled_pins {
+pinctrl-single,pins =
+0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT | MODE7 */
+0x58 0x17/* gpmc_a6.gpio1_22, OUTPUT_PULLUP | MODE7 */
+0x5C 0x7/* gpmc_a7.gpio1_23, OUTPUT | MODE7 */
+0x60 0x17/* gpmc_a8.gpio1_24, OUTPUT_PULLUP | MODE7 */
+;
+};
+};
+
Looks like this patch should also claim these pins by the led driver.
Then the led driver should just do pinctrl_get_select_default(pdev-dev)
in it's probe function to set the pins.
FWIW, I've been using this for a while now:
+ leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = beaglebone::usr0;
+ gpios = gpio2 21 0;
+ linux,default-trigger = heartbeat;
+ };
+
+ mmc {
+ label = beaglebone:usr1;
+ gpios = gpio2 22 0;
+ linux,default-trigger = mmc0;
+ };
Thanks for the inputs, similar data but not exact is added to
v5 series.
+gpio-leds {
+compatible = gpio-leds;
+pinctrl-names = default;
+pinctrl-0 = userled_pins;
+
+led0 {
+label = status:green:user0;
+gpios = gpio2 21 0;
+default-state = off;
+};
+
+led1 {
+label = status:green:user1;
+gpios = gpio2 22 0;
+default-state = off;
+};
+
+led2 {
+label = status:green:user2;
+gpios = gpio2 23 0;
+default-state = off;
+};
+
+led3 {
+label = status:green:user3;
+gpios = gpio2 24 0;
+default-state = off;
+};
+};
+
Can you review my v5 patches and tell me if there are any
modifications/changes required?
It would be nice to keep de heartbeat and mmc triggers like we have in the 3.2
kernel that ships with the bone
Thanks
AnilKumar
--
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 RESEND v4 2/3] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
Op 30 aug. 2012, om 22:35 heeft Tony Lindgren t...@atomide.com het volgende
geschreven:
* AnilKumar Ch anilku...@ti.com [120828 01:11]:
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index a7906cb..58f5042 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,6 +18,20 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+am3358_pinmux: pinmux@44E10800 {
+pinctrl-names = default;
+pinctrl-0 = userled_pins;
+
+userled_pins: pinmux_userled_pins {
+pinctrl-single,pins =
+0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
MODE7 */
+0x58 0x17 /* gpmc_a6.gpio1_22,
OUTPUT_PULLUP | MODE7 */
+0x5C 0x7/* gpmc_a7.gpio1_23, OUTPUT |
MODE7 */
+0x60 0x17 /* gpmc_a8.gpio1_24,
OUTPUT_PULLUP | MODE7 */
+;
+};
+};
+
Looks like this patch should also claim these pins by the led driver.
Then the led driver should just do pinctrl_get_select_default(pdev-dev)
in it's probe function to set the pins.
FWIW, I've been using this for a while now:
+ leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = beaglebone::usr0;
+ gpios = gpio2 21 0;
+ linux,default-trigger = heartbeat;
+ };
+
+ mmc {
+ label = beaglebone:usr1;
+ gpios = gpio2 22 0;
+ linux,default-trigger = mmc0;
+ };--
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 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? Use this repo to test on beaglebone https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl This wiki talks about how to build and use? https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree Note: Enable tps65217 regulator in kernel config. I used that repo and as a seperate test I rebased that to latest mainline, same thing: as soon as I turn on the TPS in the .config it crashes on boot. Is the pinctrl repo the *exact* repo you used to test the patches on beaglebone?-- 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 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Op 24 aug. 2012, om 09:26 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote: Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? Use this repo to test on beaglebone https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl This wiki talks about how to build and use? https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree Note: Enable tps65217 regulator in kernel config. I used that repo and as a seperate test I rebased that to latest mainline, same thing: as soon as I turn on the TPS in the .config it crashes on boot. Is the pinctrl repo the *exact* repo you used to test the patches on beaglebone? I tested on latest mainline after merging to am335x-upstream-staging-pinctrl (voltage also changing) Can you share your .config and uImage? Config: https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone My config details:- (After merge) 1. omap2plus_defconfig 2. Enable tps65217 MFD driver 3. Enable tps65217 regulator driver I rebased onto latest mainline and refreshed the base patches from Vaibhav and I now get: [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1 So it boots! I don't know what made it break before, but it's working now :) regards, Koen-- 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 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Op 24 aug. 2012, om 09:56 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 24 aug. 2012, om 09:26 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote: Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? Use this repo to test on beaglebone https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl This wiki talks about how to build and use? https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree Note: Enable tps65217 regulator in kernel config. I used that repo and as a seperate test I rebased that to latest mainline, same thing: as soon as I turn on the TPS in the .config it crashes on boot. Is the pinctrl repo the *exact* repo you used to test the patches on beaglebone? I tested on latest mainline after merging to am335x-upstream-staging-pinctrl (voltage also changing) Can you share your .config and uImage? Config: https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone My config details:- (After merge) 1. omap2plus_defconfig 2. Enable tps65217 MFD driver 3. Enable tps65217 regulator driver I rebased onto latest mainline and refreshed the base patches from Vaibhav and I now get: [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1 So it boots! I don't know what made it break before, but it's working now :) *sigh* I'm an idiot: root@beaglebone:~# uname -a Linux beaglebone 3.6.0-rc3-00103-gfd02083 #86 SMP Fri Aug 24 09:45:54 CEST 2012 armv7l GNU/Linux root@beaglebone:~# zcat /proc/config.gz | grep 217 CONFIG_MFD_TPS65217=y # CONFIG_REGULATOR_TPS65217 is not set Will retry with regulator driver actually turned on in a bit.-- 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] backlight: Add TPS65217 WLED driver
Op 22 aug. 2012, om 23:04 heeft Matthias Kaehlcke matth...@kaehlcke.net het volgende geschreven: The TPS65217 chip contains a boost converter and current sinks which can be used to drive LEDs for use as backlights. Expose this functionality via the backlight API. Tested on an AM335x based custom board with a single WLED string, using different values for ISEL and FDIM (though it would be hard to tell the difference except for the value in WLEDCTRL1). Both instantiation through the device tree and by passing platform data have been tested. Testing has been done with an Androidized 3.2 kernel from the rowboat project This patch is based on the mfd/for-next branch (20120822) Changes since v2: * adapted to the latest version of the tps65217 mfd driver * register backlight as mfd subdevice * allocate struct tps65217_bl after validation of the device tree/platform data Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net Work beautifully on a beaglebone + 3 LCD cape, although there's no FB driver yet: Tested-by: Koen Kooi k...@dominion.thruhere.net-- 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 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? -- 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] arm/dts: omap5-evm: Add keypad data
Op 3 aug. 2012, om 14:38 heeft Sourav Poddar sourav.pod...@ti.com het
volgende geschreven:
Add keypad data node in omap5 device tree file.
Also fill the device tree binding parameters
with the required value in omap5-evm dts file.
Tested on omap5430 evm with 3.5 custom kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 12
arch/arm/boot/dts/omap5.dtsi|5 +
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 45a8aeb..09fe941 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -17,6 +17,18 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ keypad {
+ keypad,num-rows = 8;
+ keypad,num-columns = 8;
+ linux,keymap = 0x02020073
+ 0x02030072
+ 0x020400e7
+ 0x02050066
+ 0x0206006b
+ 0x020700d9 ;
+ linux,input-no-autorepeat;
+ };
Again not a coment on your patch, but on DT:
If DT bindings must be OS independent, what then, is that linux keycode doing
there?
regards,
Koen
--
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: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
Op 7 aug. 2012, om 17:53 heeft Hiremath, Vaibhav hvaib...@ti.com het
volgende geschreven:
On Tue, Aug 07, 2012 at 20:49:48, Rob Herring wrote:
On 08/07/2012 08:37 AM, Vaibhav Hiremath wrote:
If the module requires only one clocksource to function, then
driver can very well call clk_get() api with con_id = NULL,
clk = clk_get(dev, NULL);
And platform code should respect this and return valid clk handle.
That means, now the clk_get() api would rely on dev_id, and platform
code should either have clk node with matching dev_id (with con_id=NULL)
or return dummy clk node.
With DT support, we can fix the dev_id for particular module
using struct of_dev_auxdata to satisfy above clk framework requirement.
In case of AM33XX, we required this for the DCAN module, so this
patch adds of_dev_auxdata for both DCAN_0/1 instances.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
This patch is boot tested on BeagleBone platform, and checked for
clk_get() return value in d_can module driver.
arch/arm/mach-omap2/board-generic.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..c9b7903 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[]
__initdata = {
{ }
};
+/*
+ * Lookup table for attaching a specific name and platform_data pointer to
+ * devices as they get created by of_platform_populate(). Ideally this
table
+ * would not exist, but the current clock implementation depends on some
devices
+ * having a specific name OR to satisfy NULL con_id requirement from
driver.
+ */
+static const struct of_dev_auxdata am33xx_auxdata_lookup[] __initconst = {
+ OF_DEV_AUXDATA(bosch,d_can, 0x481cc000, d_can.0, NULL),
+ OF_DEV_AUXDATA(bosch,d_can, 0x481d, d_can.1, NULL),
+ { },
+};
Adding an additional clkdev lookup accomplishes the same thing and is a
cleaner solution.
That is also required and I have submitted patch for the same -
http://www.spinics.net/lists/arm-kernel/msg187998.html
With DT support, I am getting dev_id as -
- Without reg property: d_can.16 and d_can.17,
(I believe it changes dynamically here)
- With reg property: 481cc000.d_can and 481d.d_can
Which is not so intuitive, I would like to see them as per Spec/TRM, so
doesn't this patch make sense?
Similar thing has already been done for other platforms too.
Davinci-mdio has a similar problem
regards,
Koen--
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/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
Op 3 aug. 2012, om 09:16 heeft Daniel Mack zon...@gmail.com het volgende geschreven: On 30.03.2012 15:27, Santosh Shilimkar wrote: For coupled cpuidle to work when both cpus are active, it needs a global timer that can handle events for both cpus. This timer is used as the broadcast clock-event when the per-cpu timer hardware stop in low power states. Set the cpumask of clockevent_gpt to all cpus, set the rating correctly, and set the irq to allow the clockevent core to determine the affinity of the timer. These patches made it to mainline now, shortly befor 3.6-rc1, and it breaks boot on my AM33xx board. Once I revert 1/3, the board boots again but crashes with the Ooops below. With the entire series reverted, everything works again as expected. Any idea? The upstream commit ids are 11d6ec2e ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus 5b4d5bcc ARM: OMAP4: CPUidle: add synchronization for coupled idle states b93d70ae ARM: OMAP4: CPUidle: Open broadcast clock-event device. I've had boot problems with cpuidle enabled as well, what happens if you disable it? Is the revert still needed in that case? I'd really want cpufreq and cpuidle to work properly, but right now I'll settle for it boots. regards, Koen-- 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/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
Op 3 aug. 2012, om 09:21 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 3 aug. 2012, om 09:16 heeft Daniel Mack zon...@gmail.com het volgende geschreven: On 30.03.2012 15:27, Santosh Shilimkar wrote: For coupled cpuidle to work when both cpus are active, it needs a global timer that can handle events for both cpus. This timer is used as the broadcast clock-event when the per-cpu timer hardware stop in low power states. Set the cpumask of clockevent_gpt to all cpus, set the rating correctly, and set the irq to allow the clockevent core to determine the affinity of the timer. These patches made it to mainline now, shortly befor 3.6-rc1, and it breaks boot on my AM33xx board. Once I revert 1/3, the board boots again but crashes with the Ooops below. With the entire series reverted, everything works again as expected. Any idea? The upstream commit ids are 11d6ec2e ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus 5b4d5bcc ARM: OMAP4: CPUidle: add synchronization for coupled idle states b93d70ae ARM: OMAP4: CPUidle: Open broadcast clock-event device. I've had boot problems with cpuidle enabled as well, what happens if you disable it? Is the revert still needed in that case? To answer my own question: No, the reverts aren't needed if you disable cpuidle.-- 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/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
Op 3 aug. 2012, om 11:27 heeft Shilimkar, Santosh santosh.shilim...@ti.com
het volgende geschreven:
On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi k...@dominion.thruhere.net wrote:
Op 3 aug. 2012, om 09:21 heeft Koen Kooi k...@dominion.thruhere.net het
volgende geschreven:
Op 3 aug. 2012, om 09:16 heeft Daniel Mack zon...@gmail.com het volgende
geschreven:
On 30.03.2012 15:27, Santosh Shilimkar wrote:
For coupled cpuidle to work when both cpus are active, it needs a global
timer
that can handle events for both cpus. This timer is used as the broadcast
clock-event when the per-cpu timer hardware stop in low power states.
Set the cpumask of clockevent_gpt to all cpus, set the rating correctly,
and
set the irq to allow the clockevent core to determine the affinity of the
timer.
These patches made it to mainline now, shortly befor 3.6-rc1, and it
breaks boot on my AM33xx board.
Once I revert 1/3, the board boots again but crashes with the Ooops
below. With the entire series reverted, everything works again as
expected. Any idea?
The upstream commit ids are
11d6ec2e ARM: OMAP: timer: allow gp timer clock-event to be used on
both cpus
5b4d5bcc ARM: OMAP4: CPUidle: add synchronization for coupled idle states
b93d70ae ARM: OMAP4: CPUidle: Open broadcast clock-event device.
I've had boot problems with cpuidle enabled as well, what happens if you
disable it? Is the revert still needed in that case?
To answer my own question: No, the reverts aren't needed if you disable
cpuidle.
This is really strange since CPUIDLE code is really OMAP4 specific.
obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o
May be omap2plus build some how the code gets executed on AMXX
Can you try below and see if the boot with CPUIDLE enabled goes away on
AMXX
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index ea24174..195e756 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -147,6 +147,9 @@ int __init omap4_pm_init(void)
struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup;
struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
+ if (!cpu_is_omap44xx())
+ return -ENODEV;
+
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, Power Management not supported on OMAP4430 ES1.0\n);
return -ENODEV;
That does seem to fix it:
root@beaglebone:~# zcat /proc/config.gz | grep -i cpu_idle
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y
root@beaglebone:~# zcat /proc/config.gz | grep -i omap4
CONFIG_ARCH_OMAP4=y
CONFIG_MACH_OMAP4_PANDA=y
# CONFIG_OMAP4_ERRATA_I688 is not set
# CONFIG_KEYBOARD_OMAP4 is not set
CONFIG_OMAP4_DSS_HDMI=y
regards,
Koen--
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/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
Op 3 aug. 2012, om 11:42 heeft Hiremath, Vaibhav hvaib...@ti.com het
volgende geschreven:
On Fri, Aug 03, 2012 at 15:03:07, Koen Kooi wrote:
Op 3 aug. 2012, om 11:27 heeft Shilimkar, Santosh
santosh.shilim...@ti.com het volgende geschreven:
On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi k...@dominion.thruhere.net
wrote:
Op 3 aug. 2012, om 09:21 heeft Koen Kooi k...@dominion.thruhere.net het
volgende geschreven:
Op 3 aug. 2012, om 09:16 heeft Daniel Mack zon...@gmail.com het
volgende geschreven:
On 30.03.2012 15:27, Santosh Shilimkar wrote:
For coupled cpuidle to work when both cpus are active, it needs a
global timer
that can handle events for both cpus. This timer is used as the
broadcast
clock-event when the per-cpu timer hardware stop in low power states.
Set the cpumask of clockevent_gpt to all cpus, set the rating
correctly, and
set the irq to allow the clockevent core to determine the affinity of
the
timer.
These patches made it to mainline now, shortly befor 3.6-rc1, and it
breaks boot on my AM33xx board.
Once I revert 1/3, the board boots again but crashes with the Ooops
below. With the entire series reverted, everything works again as
expected. Any idea?
The upstream commit ids are
11d6ec2e ARM: OMAP: timer: allow gp timer clock-event to be used on
both cpus
5b4d5bcc ARM: OMAP4: CPUidle: add synchronization for coupled idle
states
b93d70ae ARM: OMAP4: CPUidle: Open broadcast clock-event device.
I've had boot problems with cpuidle enabled as well, what happens if you
disable it? Is the revert still needed in that case?
To answer my own question: No, the reverts aren't needed if you disable
cpuidle.
This is really strange since CPUIDLE code is really OMAP4 specific.
obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o
May be omap2plus build some how the code gets executed on AMXX
Can you try below and see if the boot with CPUIDLE enabled goes away on
AMXX
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index ea24174..195e756 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -147,6 +147,9 @@ int __init omap4_pm_init(void)
struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup;
struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
+ if (!cpu_is_omap44xx())
+ return -ENODEV;
+
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, Power Management not supported on OMAP4430 ES1.0\n);
return -ENODEV;
That does seem to fix it:
root@beaglebone:~# zcat /proc/config.gz | grep -i cpu_idle
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y
root@beaglebone:~# zcat /proc/config.gz | grep -i omap4
CONFIG_ARCH_OMAP4=y
CONFIG_MACH_OMAP4_PANDA=y
# CONFIG_OMAP4_ERRATA_I688 is not set
# CONFIG_KEYBOARD_OMAP4 is not set
CONFIG_OMAP4_DSS_HDMI=y
This patch is not required, Without this patch is works for me,
I just retested and I don't need Santosh' patch, booting with cpuidle enable
works now, after refreshing your patchset (and dropping the rtc commit, it
conflicts with the other rtc patches out there).
[root@arago /]# cat /proc/version
Linux version 3.6.0-rc1-next-20120803-00010-g5f6bf0f (a0393758@psplinux064)
(gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Fri Aug 3 15:06:57
IST 2012
[root@arago /]#
Do you have below patch??
ARM: OMAP: cpu: Make cpu_class_is_omap2 true for all non-omap1 platforms
Also I have pushed branch (based on linux-next/master) to
https://github.com/hvaibhav/am335x-linux/tree/am335x-linux-next-master
Thanks! Ajays USB work and AnilKumar's pinctrl work are there as branches, any
plans to add da8xx-fb, rtc and networking branches? As you can see from the
cpsw patches, they were impossible to test because the davinci_mdio ones were
missing.
regards,
Koen--
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 v7 00/11] usb: musb: adding multi instance support
Op 3 aug. 2012, om 13:41 heeft Daniel Mack zon...@gmail.com het volgende geschreven: On 03.08.2012 11:07, Hiremath, Vaibhav wrote: I have just pushed the code (V7 which Ravi submitted), so can you please try with below branch? https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging-usb Thanks for doing this, but I'm unfortunately getting tons of merge conflicts when I try to put this on top of 3.6-rc1. Still pondering which way around is the easiest to get this solved. A number of those patches are already in 3.6rc1 (the first 10 or so). I use this set: https://github.com/beagleboard/kernel/tree/beaglebone-3.6/patches/usb Those where pulled from the staging branch and refreshed this morning. Matching git branch (will get rebased): https://github.com/koenkooi/linux/commits/beaglebone-3.6-dont-use That gives me rootfs on USB on beaglebone port1 and g_ether gadget on beaglebone port0. Hopefully this will work on your custom board as well. regards, Koen-- 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] arm/dts: omap5-evm: Add keypad data
Op 3 aug. 2012, om 14:38 heeft Sourav Poddar sourav.pod...@ti.com het
volgende geschreven:
Add keypad data node in omap5 device tree file.
Also fill the device tree binding parameters
with the required value in omap5-evm dts file.
Tested on omap5430 evm with 3.5 custom kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 12
arch/arm/boot/dts/omap5.dtsi|5 +
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 45a8aeb..09fe941 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -17,6 +17,18 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ keypad {
+ keypad,num-rows = 8;
+ keypad,num-columns = 8;
+ linux,keymap = 0x02020073
+ 0x02030072
+ 0x020400e7
+ 0x02050066
+ 0x0206006b
+ 0x020700d9 ;
+ linux,input-no-autorepeat;
+ };
This not a criticism on your patch, but a generic question about DT: Is there
no way to have nice constants for keys like we have in the kernel, like
KEY_POWER, KEY_UP, etc? If no, does DT allow comments so I can look at a dts
and see which keycodes are mapped instead of having to dig up the sources?
regards,
Koen--
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 v7 00/11] usb: musb: adding multi instance support
Op 3 aug. 2012, om 17:48 heeft Hiremath, Vaibhav hvaib...@ti.com het volgende geschreven: On Fri, Aug 03, 2012 at 17:11:38, Daniel Mack wrote: On 03.08.2012 11:07, Hiremath, Vaibhav wrote: I have just pushed the code (V7 which Ravi submitted), so can you please try with below branch? https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging-usb Thanks for doing this, but I'm unfortunately getting tons of merge conflicts when I try to put this on top of 3.6-rc1. Still pondering which way around is the easiest to get this solved. OTOH, I wonder whether your staging branches would need to rebased sooner or later anyway? I have already pushed branch based on v3.6-rc1 (boot tested), https://github.com/hvaibhav/am335x-linux/tree/am335x-linux-next-master I think Daniel meant without the linux-next stuff in between. E.g. on top of the v3.6-rc1 tag. I can see that such a tree is not of much use for you, since you now need to target the 3.7 merge window for new patches. But I can't and won't speak for both of you :) regards, Koen-- 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: Current state of AM33xx patches
Op 2 aug. 2012, om 17:30 heeft Daniel Mack zon...@gmail.com het volgende geschreven: On 31.07.2012 21:29, Koen Kooi wrote: 2/3 of the way there: http://patchwork.ozlabs.org/patch/174085/ http://patchwork.ozlabs.org/patch/174086/ I keep failing to create a .dts that doesn't upset the dtc, so I don't have it working yet :( Yes, that's because there are couple of sytax errors in the example bindings. Not only that, it's actually missing params and other params are wrong. See my non-constructive rant in the commit message: http://dominion.thruhere.net/koen/angstrom/beaglebone/0001-beaglebone-add-broken-cpsw-DT.patch But I still can't get it working: root@beaglebone:~# dmesg | grep -i cpsw [ 13.504425] net eth0: initializing cpsw version 1.12 (0) root@beaglebone:~# dmesg | grep -i phy [0.00] Booting Linux on physical CPU 0 [0.228496] nop_usb_xceiv phy.17: transceiver type USB2 PHY already exists [ 13.512056] libphy: PHY davinci_mdio-0:00 not found [ 13.517168] net eth0: phy davinci_mdio-0:00 not found on slave 0 [ 13.523516] libphy: PHY davinci_mdio-0:01 not found [ 13.528675] net eth0: phy davinci_mdio-0:01 not found on slave 1 root@beaglebone:~# ifconfig -a | grep eth eth0 Link encap:Ethernet HWaddr 00:04:9F:01:1B:B8 Mugunthan, could you repost these patches and at least copy devicetree-disc...@lists.ozlabs.org and the ARM kernel mailing list? I can't comment on the patches you sent to net...@vger.kernel.org because I'm not currently subscribed to that list. Same here, I'm only on l-o, but I guess I'll need to subscribe dt-discuss in the near future :) regards, Koen-- 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: Current state of AM33xx patches
Op 2 aug. 2012, om 21:56 heeft Daniel Mack zon...@gmail.com het volgende
geschreven:
On 02.08.2012 17:37, Koen Kooi wrote:
But I still can't get it working:
root@beaglebone:~# dmesg | grep -i cpsw [ 13.504425] net eth0:
initializing cpsw version 1.12 (0)
root@beaglebone:~# dmesg | grep -i phy [0.00] Booting Linux
on physical CPU 0 [0.228496] nop_usb_xceiv phy.17: transceiver
type USB2 PHY already exists [ 13.512056] libphy: PHY
davinci_mdio-0:00 not found [ 13.517168] net eth0: phy
davinci_mdio-0:00 not found on slave 0 [ 13.523516] libphy: PHY
davinci_mdio-0:01 not found [ 13.528675] net eth0: phy
davinci_mdio-0:01 not found on slave 1
root@beaglebone:~# ifconfig -a | grep eth eth0 Link
encap:Ethernet HWaddr 00:04:9F:01:1B:B8
Ok, I got it up and and running now on my board using the two
davinci_mdio drivers and the hwmod addition I just posted.
With those applied on top of Mugunthan work, I can link my cpsw slave
with the phy id davinci_mdio.18-:04, but the 18 is just the global
device counter which will change again once I add more devices. That
still needs some cleanup.
Anyway, at least I can boot into my NFS root now :) Koen, can you try
this on your board and see if that works for you as well?
[koen@Angstrom-F16-vm-rpm kernel]$ git diff
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index ac7fab5..c33a05d 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -33,6 +33,11 @@
};
};
+ mdio: davinci_mdio@4a101000 {
+ compatible = ti,davinci-mdio;
+ ti,hwmods = davinci_mdio;
+ };
+
mac: ethernet@4A10 {
compatible = ti,cpsw;
ti,hwmods = cpgmac0;
@@ -49,19 +54,13 @@
no_bd_ram = 0;
rx_descs = 64;
mac_control = 0x20;
- slaves = 2;
+ slaves = 1;
slave@0 {
slave_reg_ofs = 0x208;
sliver_reg_ofs = 0xd80;
- phy_id = davinci_mdio-0:00;
+ phy_id = davinci_mdio.21-:00;
mac-address = [00 04 9F 01 1B B8];
};
- slave@1 {
- slave_reg_ofs = 0x308;
- sliver_reg_ofs = 0xdc0;
- phy_id = davinci_mdio-0:01;
- mac-address = [00 04 9F 01 1B B9];
- };
};
};
leads to:
[ 14.127177] net eth0: initializing cpsw version 1.12 (0)
[ 14.135038] net eth0: phy found : id is : 0x7c0f1
[ 17.871215] libphy: davinci_mdio.21-:00 - Link is Up - 100/Full
So you can add my Tested-by: to the patches if you want :)
regards,
Koen--
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: Current state of AM33xx patches
Op 26 jul. 2012, om 19:46 heeft Daniel Mack zon...@gmail.com het volgende geschreven: On 26.07.2012 18:09, Koen Kooi wrote: Op 26 jul. 2012, om 17:58 heeft Daniel Mack zon...@gmail.com het volgende geschreven: On 26.07.2012 17:00, Koen Kooi wrote: With Ajay's usb patches you can easily boot from a usb stick, you'll only need the bootloads to be on mmc or tftp. That's what I have been doing on my beaglebone :) I'm going to update https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use linus' tree when I get a chance to test a build. Hmm, how are the patches in this repository generated? Is there a tree that has them as real commits? If only! I'm manually pulling them from the mailinglist archives and patchwork. I keep hoping for TI to put up a git tree with all their WIP stuff, but I guess that goes into the world peace and pony category of wanting things. Even with this small patchset I'm already having a ton of merge conflicts in the .dtsi files which is keeping me from posting my patches (e.g. the leds-gpio one) to the proper mailinglists. Anyway, enough ranting, mainline + those patches now works on my beaglebone so for now I'm a happy camper :) I'm not on beaglebone here, so things are different. I'd be happy to get some sniplet that make the cpsw stuff work ... 2/3 of the way there: http://patchwork.ozlabs.org/patch/174085/ http://patchwork.ozlabs.org/patch/174086/ I keep failing to create a .dts that doesn't upset the dtc, so I don't have it working yet :( regards, Koen-- 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: AM33XX: Add D_CAN device tree data
Op 25 jul. 2012, om 14:23 heeft AnilKumar Ch anilku...@ti.com het volgende
geschreven:
Add Bosch D_CAN controller device tree data to AM33XX dtsi file
by adding d_can device node with all the necessary parameters.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9b974dc..2db2ffb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -163,5 +163,10 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+ dcan1: d_can@481D {
+ compatible = bosch,d_can;
+ ti,hwmods = d_can1;
+ };
};
I scanned the linux-networking mailinglist and l-o-ml, but I can't find the
patchset that actually adds the d_can drivers, could you provide a link to
that? I have 2 different CAN capes I'd like to test on beaglebone.
regards,
Koen--
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: AM33XX: Add D_CAN device tree data
Op 26 jul. 2012, om 11:03 heeft AnilKumar, Chimata anilku...@ti.com het
volgende geschreven:
On Thu, Jul 26, 2012 at 14:16:33, Koen Kooi wrote:
Op 25 jul. 2012, om 14:23 heeft AnilKumar Ch anilku...@ti.com het volgende
geschreven:
Add Bosch D_CAN controller device tree data to AM33XX dtsi file
by adding d_can device node with all the necessary parameters.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9b974dc..2db2ffb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -163,5 +163,10 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+ dcan1: d_can@481D {
+ compatible = bosch,d_can;
+ ti,hwmods = d_can1;
+ };
};
I scanned the linux-networking mailinglist and l-o-ml, but I can't find the
patchset that actually adds the d_can drivers, could you provide a link to
that? I have 2 different CAN capes I'd like to test on beaglebone.
You can find it from linux-next or net-next trees, D_CAN support is added
to C_CAN driver.
http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;
a=commitdiff;h=69927fccd96b15bd228bb82d356a7a2a0cfaeefb
Thanks! I'll try merging net-next into l-o master and see if I can get the CAN
boards to work.
regards,
Koen--
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: Current state of AM33xx patches
Op 26 jul. 2012, om 16:52 heeft Daniel Mack zon...@gmail.com het volgende geschreven: On 23.07.2012 18:36, N, Mugunthan V wrote: On 05.07.2012 19:45, N, Mugunthan V wrote: I am working on DT support for cpsw and will be submitting the patch by July 20, 2012 Just curious - have you made any progress on that yet? I have got the runtime PM support accepted to net-next, will be working on and submitting DT support by this week. I got these updates now via mainline, thanks for your work. Could you give me some board code sniplet that makes that driver work for you? I'm asking because I fail to see the fck clock that the driver requires. I'm based on Linus' tree in the middle of the merge window, plus the am335x-upstream-staging branch of git://github.com/hvaibhav/am335x-linux.git - anything else I need to have? Once I have network up and running, I can finally boot into a shell :) With Ajay's usb patches you can easily boot from a usb stick, you'll only need the bootloads to be on mmc or tftp. That's what I have been doing on my beaglebone :) I'm going to update https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use linus' tree when I get a chance to test a build. regards, Koen-- 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: Current state of AM33xx patches
Op 26 jul. 2012, om 17:58 heeft Daniel Mack zon...@gmail.com het volgende geschreven: On 26.07.2012 17:00, Koen Kooi wrote: With Ajay's usb patches you can easily boot from a usb stick, you'll only need the bootloads to be on mmc or tftp. That's what I have been doing on my beaglebone :) I'm going to update https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use linus' tree when I get a chance to test a build. Hmm, how are the patches in this repository generated? Is there a tree that has them as real commits? If only! I'm manually pulling them from the mailinglist archives and patchwork. I keep hoping for TI to put up a git tree with all their WIP stuff, but I guess that goes into the world peace and pony category of wanting things. Even with this small patchset I'm already having a ton of merge conflicts in the .dtsi files which is keeping me from posting my patches (e.g. the leds-gpio one) to the proper mailinglists. Anyway, enough ranting, mainline + those patches now works on my beaglebone so for now I'm a happy camper :) regards, Koen-- 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] OMAP: Beagle: fix DVI GPIO request
Op 21 mei 2012, om 11:41 heeft Tomi Valkeinen het volgende geschreven: Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 (OMAP: board-files: remove custom PD GPIO handling for DVI output) moved TFP410 chip's powerdown-gpio handling from the board files to the tfp410 driver. One gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved in the Beagle board file. This causes the tfp410 driver to fail to request the gpio on Beagle, causing the driver to fail and thus the DVI output doesn't work. This patch removes the gpio_request_one() from the board file. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/board-omap3beagle.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 8ede8d2..72ad1f6 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -510,9 +510,8 @@ static void __init omap3_beagle_init(void) omap_sdrc_init(mt46h32m32lf6_sdrc_params, mt46h32m32lf6_sdrc_params); + /* DVI power down GPIO */ omap_mux_init_gpio(170, OMAP_PIN_INPUT); Wouldn't it be an output rather than an input? regards, Koen-- 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] OMAP: Beagle: fix DVI GPIO request
Op 21 mei 2012, om 13:12 heeft Tomi Valkeinen het volgende geschreven: On Mon, 2012-05-21 at 12:59 +0200, Koen Kooi wrote: Op 21 mei 2012, om 11:41 heeft Tomi Valkeinen het volgende geschreven: Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 (OMAP: board-files: remove custom PD GPIO handling for DVI output) moved TFP410 chip's powerdown-gpio handling from the board files to the tfp410 driver. One gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved in the Beagle board file. This causes the tfp410 driver to fail to request the gpio on Beagle, causing the driver to fail and thus the DVI output doesn't work. This patch removes the gpio_request_one() from the board file. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/board-omap3beagle.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 8ede8d2..72ad1f6 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -510,9 +510,8 @@ static void __init omap3_beagle_init(void) omap_sdrc_init(mt46h32m32lf6_sdrc_params, mt46h32m32lf6_sdrc_params); + /* DVI power down GPIO */ omap_mux_init_gpio(170, OMAP_PIN_INPUT); Wouldn't it be an output rather than an input? Indeed. Note that I didn't change the line above =). It seems this was changed last December: - omap_cfg_reg(J25_34XX_GPIO170); + omap_mux_init_gpio(170, OMAP_PIN_INPUT); I wonder if the mux init is even necessary. Shouldn't the bootloader set the muxes? It'd rather have the kernel reset the muxes to the proper value to ensure a known state. regards, Koen-- 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: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Op 9 mei 2012, om 02:39 heeft Woodruff, Richard het volgende geschreven: From: Hilman, Kevin Sent: Tuesday, May 08, 2012 5:17 PM A basic OMAP AVS driver has been in mainline for a long time, yet we have not seen support submitted for all of these features. 1.5/3.5 is a feature. ABB is requirement for a production useable driver. ABB/FBB is also needed for 1GHz support on omap3 based SoCs like AM37xx and DM37xx. regards, Koen-- 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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Op 2 mei 2012, om 10:47 heeft Russ Dill het volgende geschreven: [0.198272] omap-mcbsp.3: alias fck already exists [3.461212] clock: dpll1_ck failed transition to 'locked' What's happening in those 3.3 seconds? regards, Koen -- 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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Op 2 mei 2012, om 12:38 heeft Raja, Govindraj het volgende geschreven: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up) What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly. Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch Logs as in here [1]. From your log: [1.705291] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [3.726593] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller Why is the ehci stuff taking more than 2 seconds? regards, Koen-- 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/RFT 6/8] ARM: OMAP: remove unused cpu_is_omap3505()
Op 30 apr. 2012, om 11:07 heeft Jean Pihet het volgende geschreven: Kevin, On Fri, Apr 27, 2012 at 1:29 AM, Kevin Hilman khil...@ti.com wrote: The 3505 check is now unused and can be removed. There are no longer any cpu_is_* checks that depend on specific IP detection. Acked-by: Vaibhav Hiremath hvaib...@ti.com Tested-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h |8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 41f3e5a..b34bf6c 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -250,8 +250,7 @@ IS_AM_SUBCLASS(335x, 0x335) * cpu_is_omap2423(): True for OMAP2423 * cpu_is_omap2430(): True for OMAP2430 * cpu_is_omap3430(): True for OMAP3430 - * cpu_is_omap3505(): True for OMAP3505 - * cpu_is_omap3517(): True for OMAP3517 + * cpu_is_omap3517(): True for AM35x: OMAP3517, OMAP3505 Is cpu_is_omap35xx() a better name for it? No, since 3530 is the same as 3430 :( regards, Koen-- 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 08/13] Add dummy smsc911x regulators to ldp.
Op 22 mrt. 2012, om 06:19 heeft Russ Dill het volgende geschreven:
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-ldp.c |7 +++
arch/arm/mach-omap2/board-omap3evm.c |9 +
Is that evm hunk intentional?
regards,
Koen
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index d50a562a..1b60495 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -22,6 +22,7 @@
#include linux/err.h
#include linux/clk.h
#include linux/spi/spi.h
+#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
#include linux/io.h
@@ -410,8 +411,14 @@ static struct mtd_partition ldp_nand_partitions[] = {
};
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
static void __init omap_ldp_init(void)
{
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
ldp_init_smsc911x();
omap_i2c_init();
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 548e1ef..a659e19 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -114,6 +114,15 @@ static struct omap_smsc911x_platform_data smsc911x_cfg =
{
static inline void __init omap3evm_init_smsc911x(void)
{
+ struct clk *l3ck;
+ unsigned int rate;
+
+ l3ck = clk_get(NULL, l3_ck);
+ if (IS_ERR(l3ck))
+ rate = 1;
+ else
+ rate = clk_get_rate(l3ck);
+
/* Configure ethernet controller reset gpio */
if (cpu_is_omap3430()) {
if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
--
1.7.9.1
--
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 09/13] Add dummy smsc911x regulators to omap3evm.
Op 22 mrt. 2012, om 06:19 heeft Russ Dill het volgende geschreven:
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a659e19..6a5e57c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -114,15 +114,6 @@ static struct omap_smsc911x_platform_data smsc911x_cfg =
{
static inline void __init omap3evm_init_smsc911x(void)
{
- struct clk *l3ck;
- unsigned int rate;
-
- l3ck = clk_get(NULL, l3_ck);
- if (IS_ERR(l3ck))
- rate = 1;
- else
- rate = clk_get_rate(l3ck);
The above hunk gets added/removed multiple times during this patch series, a
rebase -i mishap?
regards,
Koen--
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
IVA and SGX not getting detected on 3630 ES1.2
Hi, I have a freshly built beagleboard xM on my desk which is giving me some trouble: xM revision A: [0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) new xM revision C: [0.00] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk ) So the IVA and SGX aren't getting detected, while they *are* present. Any hints where I should look to debug this? regards, Koen-- 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
