Re: [RFC PATCH 4/4] ARM: dts: am33xx: adopt to cpsw-phy-sel driver to configure phy mode
On Sunday 08 September 2013 11:34 PM, Sergei Shtylyov wrote:
Hello.
On 09/08/2013 03:23 PM, Mugunthan V N wrote:
Add DT entries for the phy mode selection in AM33xx SoC using
cpsw-phy-sel
driver.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..4359672 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -594,6 +594,12 @@
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
+
+phy_sel: cpsw_phy_sel@44e10650 {
Dashes are preferred to uderscores in the device tree names.
I tried with dashes but i get the below error.
$ make CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm dtbs
DTC arch/arm/boot/dts/am335x-evm.dtb
Error: arch/arm/boot/dts/am33xx.dtsi:598.11-12 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [arch/arm/boot/dts/am335x-evm.dtb] Error 1
make: *** [dtbs] Error 2
Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] cpsw: support for control module register
On 08.09.2013 13:23, Mugunthan V N wrote: This patch series adds the support for configuring GMII_SEL register of control module to select the phy mode type and also to configure the clock source for RMII phy mode whether to use internal clock or the external clock from the phy itself. Till now CPSW works as this configuration is done in U-Boot and carried over to the kernel. But during suspend/resume Control module tends to lose its configured value for GMII_SEL register in AM33xx PG1.0, so if CPSW is used in RMII or RGMII mode, on resume cpsw is not working as GMII_SEL register lost its configuration values. The initial version of the patch is done by Daniel Mack but as per Tony's comment he wants it as a seperate driver as it is done in USB control module. I have created a seperate driver for the same and as the merge window is open now and no feature request is accepted I am submitting it as RFC for reviews. Thanks for doing this. It's a somehow expensive approach of writing a single 32bit register, but I agree it's cleaner to not have this code in the cpsw driver directly. For the whole series: Tested-by: Daniel Mack zon...@gmail.com Daniel -- 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 RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver
Am Donnerstag, den 05.09.2013, 21:26 +0530 schrieb Afzal Mohammed:
Hi Philipp,
On Thursday 05 September 2013 03:37 PM, Philipp Zabel wrote:
Am Montag, den 02.09.2013, 19:41 +0530 schrieb Afzal Mohammed:
Two new reset API's are provided to check whether reset is ready and
to clear reset. This would be required in case IP needs to mix reset
handling procedure with power/clock managment procedure to achieve
proper reset and these procedures are sometimes IP specific that would
make it difficult to handle reset fully in pm_runtime platform support.
client IP handling s/w (DT based) should do as follows:
2. In driver, that require reset to be deasserted,
(this is the sequence required for gfx on AM43x/AM335x, this would
depend on requirements of the IP)
mydriver_probe(struct platform device *pdev)
{
:
:
reset_control_get(pdev-dev, NULL);
reset_control_clear_reset();
reset_control_deassert();
pm_runtime_get_sync();
if (reset_control_is_reset() != true)
goto err;
reset_control_put();
:
:
}
if possible, I'd like to move this logic into the reset controller
driver. Can this be reordered to enable power before deasserting the
reset line (assuming it is initially asserted)? In this case, I'd
suggest to just call device_reset:
pm_runtime_get_sync(pdev-dev);
ret = device_reset(pdev-dev);
if (ret)
goto err;
The ops.reset callback in the prcm driver then can handle clearing
the reset status bit, deasserting the reset control bit, and waiting for
the reset status bit to be set (or timing out with an error).
I too would have loved to have it in such a clean way and was initially
proceeding in that direction, but there is an issue specific to OMAP
family SoC's, which was required to be taken care of (even though
present use case for AM335x/AM43x would work [as it does not have
hardware supervised clockdomain mode] with a small change in platform
level power management support code - a generic one shared with other
OMAP family SoC's)
For a module to be reset, clock domain to which the module clock belongs
should be set to software supervised mode. During pm_runtime_get_sync,
in OMAP platform level handling code, it first put clockdomain into
software supervised mode, enables clock to module, and once module is
ready, module will be put to hardware supervised mode. In hardware
supervised mode, reset may not happen.
So if device_reset() is done after pm_runtime_get_sync(), reset may not
happen as by the time device_reset() is called, clockdomain would be in
hardware supervised mode. But in other case, as reset is already
deasserted when pm_runtime_get_sync() is called, module would be reset
as it first puts to software supervised mode.
And device reset would happen only upon enabling clock to module (if
reset was deasserted) by pm_runtime_get_sync(), so reset status has to
be checked after pm call, preventing us having device_reset() before
pm_runtime_get_sync(), or else in that case we have to sacrifice on
reset status checking (which may not be reliable)
Another alternative would have been to integrate this reset handling in
low level power management code thus hiding all reset handling from
driver, but as far as I know the reset sequence to be done is sometimes
IP specific, preventing it.
So if I understand correctly, the only problem is that on OMAP the clock
needs to be enabled to deassert the reset, but as long as the clock
domain is in hardware supervised mode, it won't be enabled?
Would it be possible to create an internal API to switch the clock
domain to software supervised mode, which can be used both by the code
behind pm_runtime_get_sync and reset_control_deassert?
regards
Philipp
--
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: Build error in torvalds kernel 3.11 for omap2plus
On Sun, Sep 08, 2013 at 10:16:14AM -0700, Guenter Roeck wrote: Since we are at it: Build reference: v3.11-7887-gb409624 Building arm:defconfig ... passed Building arm:allmodconfig ... failed -- Error log: arch/arm/mach-cns3xxx/pcie.c: In function 'cns3xxx_pcie_hw_init': arch/arm/mach-cns3xxx/pcie.c:350:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] /tmp/cce439dZ.s: Assembler messages: /tmp/cce439dZ.s:506: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:512: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:513: Error: selected processor does not support ARM mode `dsb ' /tmp/cce439dZ.s:583: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:589: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:590: Error: selected processor does not support ARM mode `dsb ' make[1]: *** [arch/arm/mach-vexpress/dcscb.o] Error 1 make: *** [arch/arm/mach-vexpress] Error 2 make: *** Waiting for unfinished jobs -- Any solution for this one ? omap2plus passes for me. gcc version used is arm-poky-linux-gnueabi-gcc (GCC) 4.7.2 from poky 1.3. That's due to: commit e8f9bb1bd6bb93fff773345cc54c42585e0e3ece Author: Nicolas Pitre nicolas.pi...@linaro.org Date: Tue Jul 16 20:59:53 2013 -0400 ARM: vexpress/dcscb: fix cache disabling sequences Unlike real A15/A7's, the RTSM simulation doesn't appear to hit the cache when the CTRL.C bit is cleared. Let's ensure there is no memory access within the disable and flush cache sequence, including to the stack. Signed-off-by: Nicolas Pitre n...@linaro.org which introduces some 'isb' and 'dsb' instructions which are not available on ARMv6 CPUs - however, their 'mcr' equivalents are. Either dcscb needs to be built with an -march=armv7 override, or they need to use the mcr equivalent instructions. -- 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: Build error in torvalds kernel 3.11 for omap2plus
Hi Guenter, On Sun, Sep 8, 2013 at 10:46 PM, Guenter Roeck li...@roeck-us.net wrote: On 09/08/2013 02:02 AM, Russell King - ARM Linux wrote: On Sun, Sep 08, 2013 at 11:34:10AM +0530, Anil Kumar wrote: scripts/kconfig/conf --silentoldconfig Kconfig CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h AS arch/arm/mm/cache-v7.o arch/arm/mm/cache-v7.S: Assembler messages: arch/arm/mm/cache-v7.S:285: Error: garbage following instruction -- `dsb ishst' arch/arm/mm/cache-v7.S:297: Error: garbage following instruction -- `dsb ishst' make[1]: *** [arch/arm/mm/cache-v7.o] Error 1 make: *** [arch/arm/mm] Error 2 You need a later binutils for these instructions - 2.22 works just fine, even with gcc 4.5.x. Since we are at it: Build reference: v3.11-7887-gb409624 Building arm:defconfig ... passed Building arm:allmodconfig ... failed -- Error log: arch/arm/mach-cns3xxx/pcie.c: In function 'cns3xxx_pcie_hw_init': arch/arm/mach-cns3xxx/pcie.c:350:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] /tmp/cce439dZ.s: Assembler messages: /tmp/cce439dZ.s:506: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:512: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:513: Error: selected processor does not support ARM mode `dsb ' /tmp/cce439dZ.s:583: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:589: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:590: Error: selected processor does not support ARM mode `dsb ' make[1]: *** [arch/arm/mach-vexpress/dcscb.o] Error 1 make: *** [arch/arm/mach-vexpress] Error 2 make: *** Waiting for unfinished jobs -- Any solution for this one ? omap2plus passes for me. I have updated my toolchain Assembler (used binutils 2.22 ) with latest one and issue has fixed. Thanks, Anil -- 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: Build error in torvalds kernel 3.11 for omap2plus
On 09/09/2013 03:55 AM, Anil Kumar wrote: Hi Guenter, On Sun, Sep 8, 2013 at 10:46 PM, Guenter Roeck li...@roeck-us.net wrote: On 09/08/2013 02:02 AM, Russell King - ARM Linux wrote: On Sun, Sep 08, 2013 at 11:34:10AM +0530, Anil Kumar wrote: scripts/kconfig/conf --silentoldconfig Kconfig CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h AS arch/arm/mm/cache-v7.o arch/arm/mm/cache-v7.S: Assembler messages: arch/arm/mm/cache-v7.S:285: Error: garbage following instruction -- `dsb ishst' arch/arm/mm/cache-v7.S:297: Error: garbage following instruction -- `dsb ishst' make[1]: *** [arch/arm/mm/cache-v7.o] Error 1 make: *** [arch/arm/mm] Error 2 You need a later binutils for these instructions - 2.22 works just fine, even with gcc 4.5.x. Since we are at it: Build reference: v3.11-7887-gb409624 Building arm:defconfig ... passed Building arm:allmodconfig ... failed -- Error log: arch/arm/mach-cns3xxx/pcie.c: In function 'cns3xxx_pcie_hw_init': arch/arm/mach-cns3xxx/pcie.c:350:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] /tmp/cce439dZ.s: Assembler messages: /tmp/cce439dZ.s:506: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:512: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:513: Error: selected processor does not support ARM mode `dsb ' /tmp/cce439dZ.s:583: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:589: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:590: Error: selected processor does not support ARM mode `dsb ' make[1]: *** [arch/arm/mach-vexpress/dcscb.o] Error 1 make: *** [arch/arm/mach-vexpress] Error 2 make: *** Waiting for unfinished jobs -- Any solution for this one ? omap2plus passes for me. I have updated my toolchain Assembler (used binutils 2.22 ) with latest one and issue has fixed. Not for this build. As I said, the omap2plus build passes for me. My binutils version is 2.23.1.20121113. Did you try to build the file after make allmodconfig ? Guenter -- 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: Build error in torvalds kernel 3.11 for omap2plus
On 09/09/2013 03:51 AM, Russell King - ARM Linux wrote: On Sun, Sep 08, 2013 at 10:16:14AM -0700, Guenter Roeck wrote: Since we are at it: Build reference: v3.11-7887-gb409624 Building arm:defconfig ... passed Building arm:allmodconfig ... failed -- Error log: arch/arm/mach-cns3xxx/pcie.c: In function 'cns3xxx_pcie_hw_init': arch/arm/mach-cns3xxx/pcie.c:350:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] /tmp/cce439dZ.s: Assembler messages: /tmp/cce439dZ.s:506: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:512: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:513: Error: selected processor does not support ARM mode `dsb ' /tmp/cce439dZ.s:583: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:589: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:590: Error: selected processor does not support ARM mode `dsb ' make[1]: *** [arch/arm/mach-vexpress/dcscb.o] Error 1 make: *** [arch/arm/mach-vexpress] Error 2 make: *** Waiting for unfinished jobs -- Any solution for this one ? omap2plus passes for me. gcc version used is arm-poky-linux-gnueabi-gcc (GCC) 4.7.2 from poky 1.3. That's due to: commit e8f9bb1bd6bb93fff773345cc54c42585e0e3ece Author: Nicolas Pitre nicolas.pi...@linaro.org Date: Tue Jul 16 20:59:53 2013 -0400 ARM: vexpress/dcscb: fix cache disabling sequences Unlike real A15/A7's, the RTSM simulation doesn't appear to hit the cache when the CTRL.C bit is cleared. Let's ensure there is no memory access within the disable and flush cache sequence, including to the stack. Signed-off-by: Nicolas Pitre n...@linaro.org which introduces some 'isb' and 'dsb' instructions which are not available on ARMv6 CPUs - however, their 'mcr' equivalents are. Either dcscb needs to be built with an -march=armv7 override, or they need to use the mcr equivalent instructions. Well, I hope it will get fixed one way or another. I don't know enough about arm to fix it myself. Guenter -- 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/1] OMAP2+: mux: fix trivial typo in name
Signed-off-by: Phil Carmody phil.carm...@partner.samsung.com
---
arch/arm/mach-omap2/mux34xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/mux34xx.c b/arch/arm/mach-omap2/mux34xx.c
index c53609f4..be271f1 100644
--- a/arch/arm/mach-omap2/mux34xx.c
+++ b/arch/arm/mach-omap2/mux34xx.c
@@ -620,7 +620,7 @@ static struct omap_mux __initdata omap3_muxmodes[] = {
uart1_rts, ssi1_flag_tx, NULL, NULL,
gpio_149, NULL, NULL, safe_mode),
_OMAP3_MUXENTRY(UART1_RX, 151,
- uart1_rx, ss1_wake_tx, mcbsp1_clkr, mcspi4_clk,
+ uart1_rx, ssi1_wake_tx, mcbsp1_clkr, mcspi4_clk,
gpio_151, NULL, NULL, safe_mode),
_OMAP3_MUXENTRY(UART1_TX, 148,
uart1_tx, ssi1_dat_tx, NULL, NULL,
--
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
Re: [PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
On 09/08/2013 07:12 AM, 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 Grabbed my beaglebone white and black and tested them both on top of e5c832d (top of Linus' tree atm), came up with a ramdisk. Tested-by: Tom Rini tr...@ti.com -- Tom -- 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: [PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
On Sun, Sep 08, 2013 at 01:12:26PM +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: Matt Porter matt.por...@linaro.org Works fine for me on tip and 3.11. I did notice a regression in musb (worked on 3.11, now failing to probe but this is not related to your new dts as it happens on am335x-bone.dts too, assuming merge window volatility). One nit, git-am picked up a whitespace error on that extra line at EOF so you should trim that out. Only thing is...for a clear bug like this that will destroy hardware, it should be marked Cc: sta...@vger.kernel.org to be picked up in stable. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger
Hi Pali, On Sun, Sep 08, 2013 at 10:50:39AM +0200, Pali Rohár wrote: This patch will register bq24150a charger in RX-51 board data. Patch also adding platform function between isp1704 and bq2415x drivers for detecting charger type. So finally charging battery on Nokia N900 (RX-51) working automatically without any proprietary Nokia bits in userspace. cool :) index 9c2dd10..a993ffe 100644 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c AFAIK platform code for omap3 based boards is supposed to be removed in the near future [0]. Device Tree does not support the glue layer, so probably a small rx51 specific driver is needed. [0] https://lkml.org/lkml/2013/8/12/70 -- Sebastian signature.asc Description: Digital signature
[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: [PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
Hi Matt, On 09/09/13 14:31, Matt Porter wrote: On Sun, Sep 08, 2013 at 01:12:26PM +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: Matt Porter matt.por...@linaro.org Works fine for me on tip and 3.11. I did notice a regression in musb (worked on 3.11, now failing to probe but this is not related to your new dts as it happens on am335x-bone.dts too, assuming merge window volatility). One nit, git-am picked up a whitespace error on that extra line at EOF so you should trim that out. Only thing is...for a clear bug like this that will destroy hardware, it should be marked Cc: sta...@vger.kernel.org to be picked up in stable. If I've understood Koen correctly then what he's saying is that if you *were* to use the current (before this patch) am335x-bone.dts on a Beagle Bone Black (which would be wrong, as that's not the board you have...) then things would break. I don't see that this patch fixes that - as far as I can see, even after the patch, using am335x-bone.dts with a Bone Black will risk the damage? If so, I don't think this is a 'stable fix' kind of thing, as it doesn't actually fix the problem? Koen - is there a way for a booting kernel to detect which board it is on and avoid any potential damage if someone gives it the wrong DT? Jonny -Matt ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: [PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
On Mon, Sep 09, 2013 at 02:51:13PM +0100, Jonathan Austin wrote: Hi Matt, On 09/09/13 14:31, Matt Porter wrote: On Sun, Sep 08, 2013 at 01:12:26PM +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: Matt Porter matt.por...@linaro.org Works fine for me on tip and 3.11. I did notice a regression in musb (worked on 3.11, now failing to probe but this is not related to your new dts as it happens on am335x-bone.dts too, assuming merge window volatility). One nit, git-am picked up a whitespace error on that extra line at EOF so you should trim that out. Only thing is...for a clear bug like this that will destroy hardware, it should be marked Cc: sta...@vger.kernel.org to be picked up in stable. If I've understood Koen correctly then what he's saying is that if you *were* to use the current (before this patch) am335x-bone.dts on a Beagle Bone Black (which would be wrong, as that's not the board you have...) then things would break. I don't see that this patch fixes that - as far as I can see, even after the patch, using am335x-bone.dts with a Bone Black will risk the damage? If so, I don't think this is a 'stable fix' kind of thing, as it doesn't actually fix the problem? It fixes the problem by providing the correct dts for BBB which the vendor tree has had for sometime. In the absence of a specific dts for BBB, it appears everybody (TI and OMAP maintainers, included) has assumed that am335x-bone.dts is correct and safe. I'm sure there's plenty of systems represented in dts/* where you could cause damage by loading another dtb for a similar board from the same SoC family...it's a common risk if you get the wrong dtb with more-or-less arbitrary regulator settings. -Matt Koen - is there a way for a booting kernel to detect which board it is on and avoid any potential damage if someone gives it the wrong DT? Jonny -Matt ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: [PATCHv4] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
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 --- formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter -- 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: [PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
On Mon, Sep 09, 2013 at 09:59:26AM -0400, Matt Porter wrote: On Mon, Sep 09, 2013 at 02:51:13PM +0100, Jonathan Austin wrote: Hi Matt, On 09/09/13 14:31, Matt Porter wrote: On Sun, Sep 08, 2013 at 01:12:26PM +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: Matt Porter matt.por...@linaro.org Works fine for me on tip and 3.11. I did notice a regression in musb (worked on 3.11, now failing to probe but this is not related to your new dts as it happens on am335x-bone.dts too, assuming merge window volatility). One nit, git-am picked up a whitespace error on that extra line at EOF so you should trim that out. Only thing is...for a clear bug like this that will destroy hardware, it should be marked Cc: sta...@vger.kernel.org to be picked up in stable. If I've understood Koen correctly then what he's saying is that if you *were* to use the current (before this patch) am335x-bone.dts on a Beagle Bone Black (which would be wrong, as that's not the board you have...) then things would break. I don't see that this patch fixes that - as far as I can see, even after the patch, using am335x-bone.dts with a Bone Black will risk the damage? If so, I don't think this is a 'stable fix' kind of thing, as it doesn't actually fix the problem? It fixes the problem by providing the correct dts for BBB which the vendor tree has had for sometime. In the absence of a specific dts for BBB, it appears everybody (TI and OMAP maintainers, included) has assumed that am335x-bone.dts is correct and safe. I'm sure there's plenty of systems represented in dts/* where you could cause damage by loading another dtb for a similar board from the same SoC family...it's a common risk if you get the wrong dtb with more-or-less arbitrary regulator settings. Sorry to reply to myself, but I probably didn't make it 100% clear as to why this effectively fixes the problem. Both mainline u-boot *and* the vendor u-boot have findfdt implemented to load an am335x-boneblack.dtb based on board detection. Hopefully this makes it clear why this fixes a bug in the kernel. If you use appended dtb to include the wrong one, well, you shouldn't be using appended dtb. It's a *hack* and loading it separately works fine if you use the U-Boot that ships with BBB or mainline. -Matt Koen - is there a way for a booting kernel to detect which board it is on and avoid any potential damage if someone gives it the wrong DT? Jonny -Matt ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: [PATCHv4] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
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 ? Other than that, patch looks ok to me. -- balbi signature.asc Description: Digital signature
Re: Build error in torvalds kernel 3.11 for omap2plus
On Mon, 9 Sep 2013, Guenter Roeck wrote: On 09/09/2013 03:51 AM, Russell King - ARM Linux wrote: On Sun, Sep 08, 2013 at 10:16:14AM -0700, Guenter Roeck wrote: Since we are at it: Build reference: v3.11-7887-gb409624 Building arm:defconfig ... passed Building arm:allmodconfig ... failed -- Error log: arch/arm/mach-cns3xxx/pcie.c: In function 'cns3xxx_pcie_hw_init': arch/arm/mach-cns3xxx/pcie.c:350:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] /tmp/cce439dZ.s: Assembler messages: /tmp/cce439dZ.s:506: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:512: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:513: Error: selected processor does not support ARM mode `dsb ' /tmp/cce439dZ.s:583: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:589: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:590: Error: selected processor does not support ARM mode `dsb ' make[1]: *** [arch/arm/mach-vexpress/dcscb.o] Error 1 make: *** [arch/arm/mach-vexpress] Error 2 make: *** Waiting for unfinished jobs -- Any solution for this one ? omap2plus passes for me. gcc version used is arm-poky-linux-gnueabi-gcc (GCC) 4.7.2 from poky 1.3. That's due to: commit e8f9bb1bd6bb93fff773345cc54c42585e0e3ece Author: Nicolas Pitre nicolas.pi...@linaro.org Date: Tue Jul 16 20:59:53 2013 -0400 ARM: vexpress/dcscb: fix cache disabling sequences Unlike real A15/A7's, the RTSM simulation doesn't appear to hit the cache when the CTRL.C bit is cleared. Let's ensure there is no memory access within the disable and flush cache sequence, including to the stack. Signed-off-by: Nicolas Pitre n...@linaro.org which introduces some 'isb' and 'dsb' instructions which are not available on ARMv6 CPUs - however, their 'mcr' equivalents are. Either dcscb needs to be built with an -march=armv7 override, or they need to use the mcr equivalent instructions. Well, I hope it will get fixed one way or another. I don't know enough about arm to fix it myself. Would you try this patch please: diff --git a/arch/arm/mach-vexpress/Makefile b/arch/arm/mach-vexpress/Makefile index 36ea824712..505e64ab3e 100644 --- a/arch/arm/mach-vexpress/Makefile +++ b/arch/arm/mach-vexpress/Makefile @@ -7,6 +7,8 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ obj-y := v2m.o obj-$(CONFIG_ARCH_VEXPRESS_CA9X4) += ct-ca9x4.o obj-$(CONFIG_ARCH_VEXPRESS_DCSCB) += dcscb.o dcscb_setup.o +CFLAGS_dcscb.o += -march=armv7-a obj-$(CONFIG_ARCH_VEXPRESS_TC2_PM) += tc2_pm.o spc.o +CFLAGS_tc2_pm.o+= -march=armv7-a obj-$(CONFIG_SMP) += platsmp.o obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o -- 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: [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
On Mon, Sep 9, 2013 at 7:50 AM, Kevin Hilman khil...@linaro.org wrote:
Koen Kooi k...@dominion.thruhere.net writes:
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.
In the meantime, can you resubmit the minimal splitup with the LDO
change?
doh, I see you already did, sorry for the noise.
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
Koen Kooi k...@dominion.thruhere.net writes:
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.
In the meantime, can you resubmit the minimal splitup with the LDO
change?
Thanks,
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build error in torvalds kernel 3.11 for omap2plus
On Mon, Sep 09, 2013 at 10:24:42AM -0400, Nicolas Pitre wrote: On Mon, 9 Sep 2013, Guenter Roeck wrote: On 09/09/2013 03:51 AM, Russell King - ARM Linux wrote: On Sun, Sep 08, 2013 at 10:16:14AM -0700, Guenter Roeck wrote: Since we are at it: Build reference: v3.11-7887-gb409624 Building arm:defconfig ... passed Building arm:allmodconfig ... failed -- Error log: arch/arm/mach-cns3xxx/pcie.c: In function 'cns3xxx_pcie_hw_init': arch/arm/mach-cns3xxx/pcie.c:350:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] /tmp/cce439dZ.s: Assembler messages: /tmp/cce439dZ.s:506: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:512: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:513: Error: selected processor does not support ARM mode `dsb ' /tmp/cce439dZ.s:583: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:589: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:590: Error: selected processor does not support ARM mode `dsb ' make[1]: *** [arch/arm/mach-vexpress/dcscb.o] Error 1 make: *** [arch/arm/mach-vexpress] Error 2 make: *** Waiting for unfinished jobs -- Any solution for this one ? omap2plus passes for me. gcc version used is arm-poky-linux-gnueabi-gcc (GCC) 4.7.2 from poky 1.3. That's due to: commit e8f9bb1bd6bb93fff773345cc54c42585e0e3ece Author: Nicolas Pitre nicolas.pi...@linaro.org Date: Tue Jul 16 20:59:53 2013 -0400 ARM: vexpress/dcscb: fix cache disabling sequences Unlike real A15/A7's, the RTSM simulation doesn't appear to hit the cache when the CTRL.C bit is cleared. Let's ensure there is no memory access within the disable and flush cache sequence, including to the stack. Signed-off-by: Nicolas Pitre n...@linaro.org which introduces some 'isb' and 'dsb' instructions which are not available on ARMv6 CPUs - however, their 'mcr' equivalents are. Either dcscb needs to be built with an -march=armv7 override, or they need to use the mcr equivalent instructions. Well, I hope it will get fixed one way or another. I don't know enough about arm to fix it myself. Would you try this patch please: diff --git a/arch/arm/mach-vexpress/Makefile b/arch/arm/mach-vexpress/Makefile index 36ea824712..505e64ab3e 100644 --- a/arch/arm/mach-vexpress/Makefile +++ b/arch/arm/mach-vexpress/Makefile @@ -7,6 +7,8 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ obj-y:= v2m.o obj-$(CONFIG_ARCH_VEXPRESS_CA9X4)+= ct-ca9x4.o obj-$(CONFIG_ARCH_VEXPRESS_DCSCB)+= dcscb.o dcscb_setup.o obj-$(CONFIG_ARCH_VEXPRESS_DCSCB)+= dcscb.o dcscb_setup.o +CFLAGS_dcscb.o += -march=armv7-a obj-$(CONFIG_ARCH_VEXPRESS_TC2_PM) += tc2_pm.o spc.o +CFLAGS_tc2_pm.o += -march=armv7-a obj-$(CONFIG_SMP)+= platsmp.o obj-$(CONFIG_HOTPLUG_CPU)+= hotplug.o That fixes this problem. I'll leave it up to you and Russell to decide if it is the proper fix. Unfortunately, there are more problems. arch/arm/kernel/built-in.o: In function `ret_fast_syscall': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:42: undefined reference to `user_enter' arch/arm/kernel/built-in.o: In function `no_work_pending': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:77: undefined reference to `user_enter' arch/arm/kernel/built-in.o: In function `vector_swi': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:376: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__dabt_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:365: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__irq_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:375: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__und_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:388: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__pabt_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:662: undefined reference to `user_exit' arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init': /home/groeck/src/linux-stable/arch/arm/mach-omap2/board-omap3evm.c:703: undefined reference to `usb_nop_xceiv_register' The undefined reference to usb_nop_xceiv_register is
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: [PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
Hi Matt, On 09/09/13 15:16, Matt Porter wrote: On Mon, Sep 09, 2013 at 09:59:26AM -0400, Matt Porter wrote: On Mon, Sep 09, 2013 at 02:51:13PM +0100, Jonathan Austin wrote: Hi Matt, On 09/09/13 14:31, Matt Porter wrote: On Sun, Sep 08, 2013 at 01:12:26PM +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: Matt Porter matt.por...@linaro.org Works fine for me on tip and 3.11. I did notice a regression in musb (worked on 3.11, now failing to probe but this is not related to your new dts as it happens on am335x-bone.dts too, assuming merge window volatility). One nit, git-am picked up a whitespace error on that extra line at EOF so you should trim that out. Only thing is...for a clear bug like this that will destroy hardware, it should be marked Cc: sta...@vger.kernel.org to be picked up in stable. If I've understood Koen correctly then what he's saying is that if you *were* to use the current (before this patch) am335x-bone.dts on a Beagle Bone Black (which would be wrong, as that's not the board you have...) then things would break. I don't see that this patch fixes that - as far as I can see, even after the patch, using am335x-bone.dts with a Bone Black will risk the damage? If so, I don't think this is a 'stable fix' kind of thing, as it doesn't actually fix the problem? It fixes the problem by providing the correct dts for BBB which the vendor tree has had for sometime. In the absence of a specific dts for BBB, it appears everybody (TI and OMAP maintainers, included) has assumed that am335x-bone.dts is correct and safe. I'm sure there's plenty of systems represented in dts/* where you could cause damage by loading another dtb for a similar board from the same SoC family...it's a common risk if you get the wrong dtb with more-or-less arbitrary regulator settings. Sorry to reply to myself, but I probably didn't make it 100% clear as to why this effectively fixes the problem. Both mainline u-boot *and* the vendor u-boot have findfdt implemented to load an am335x-boneblack.dtb based on board detection. This makes more sense now, thanks. Not sure that it is still a good case for CC:stable. Are people currently working around findfdt failing, etc? If so, do you think backporting the fix will stop them doing that? I don't really know what the workflow looks like... Generally the idea of backporting DT fixes to older kernels gives me the Heebie-Jeebies - this case of being able to damage hardware is a great example of why it might be scary (though I acknowledge that this specific patch is unlikely to have a bad outcome) Jonny Hopefully this makes it clear why this fixes a bug in the kernel. If you use appended dtb to include the wrong one, well, you shouldn't be using appended dtb. It's a *hack* and loading it separately works fine if you use the U-Boot that ships with BBB or mainline. -Matt Koen - is there a way for a booting kernel to detect which board it is on and avoid any potential damage if someone gives it the wrong DT? Jonny -Matt ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: [PATCHv4] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
Hi, On Mon, Sep 09, 2013 at 04:26:38PM +0200, Koen Kooi wrote: 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. How would you ever use RF cape with HDMI on BBB ? It doesn't matter the amount of code TI (or whoever else) writes down, that will never work fine. -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
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. 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
Re: [PATCH v2] ARM: omap2: throw the die id into the entropy pool
Hi Linus, On Thu, 5 Sep 2013, Linus Walleij wrote: Atleast eight bytes of this number are totally unique for the device it seems, so this is a perfect candidate for feeding the entropy pool. One byte more or less of constants does not matter so feed in the entire OID struct. Cc: Theodore Ts'o ty...@mit.edu Cc: Paul Walmsley p...@pwsan.com Reviewed-by: Kevin Hilman khil...@linaro.org Signed-off-by: Linus Walleij linus.wall...@linaro.org Heh, that function name add_device_randomness() is a bit misleading. It's not actually intended to add randomness: from drivers/char/random.c: /* * Add device- or boot-specific data to the input and nonblocking * pools to help initialize them to unique values. * * None of this adds any entropy, it is meant to avoid the * problem of the nonblocking pool having similar initial state * across largely identical devices. */ But of course the function name is not your fault :-) The entropy count isn't increased by this, so: Reviewed-by: Paul Walmsley p...@pwsan.com Thanks Linus. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 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
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. Thanks, -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
Re: [PATCH] ARM: DTS: DRA7: Add TPS659038 PMIC nodes
On 08/26/2013 12:36 AM, Keerthy wrote:
The Patch adds nodes for TPS659038 PMIC for DRA7 boards.
It is based on top of:
http://comments.gmane.org/gmane.linux.ports.arm.omap/102459.
Documentation:Documentation/devicetree/bindings/mfd/palmas.txt
Documentation/devicetree/bindings/regulator/palmas-pmic.txt
Boot Tested on DRA7 d1 Board.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 118
1 file changed, 118 insertions(+)
Index: linux/arch/arm/boot/dts/dra7-evm.dts
===
--- linux.orig/arch/arm/boot/dts/dra7-evm.dts 2013-08-26 09:57:52.496173554
+0530
+++ linux/arch/arm/boot/dts/dra7-evm.dts 2013-08-26 10:38:44.995414695
+0530
@@ -93,6 +93,119 @@
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ tps659038: tps659038@58 {
+ compatible = ti,tps659038;
+ reg = 0x58;
+
+ tps659038_pmic {
+ compatible = ti,tps659038-pmic;
+
+ regulators {
+ smps123_reg: smps123 {
+ /* VDD_MPU */
+ regulator-name = smps123;
+ regulator-min-microvolt =
85;
+ regulator-max-microvolt =
125;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ /* VDD_DSPEVE */
+ regulator-name = smps45;
+ regulator-min-microvolt =
85;
+ regulator-max-microvolt =
115;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ /* VDD_GPU - over VDD_SMPS6 */
+ regulator-name = smps6;
+ regulator-min-microvolt =
85;
+ regulator-max-microvolt =
1250;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ /* CORE_VDD */
+ regulator-name = smps7;
+ regulator-min-microvolt =
85;
+ regulator-max-microvolt =
103;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ /* VDD_IVAHD */
+ regulator-name = smps8;
+ regulator-min-microvolt =
85;
+ regulator-max-microvolt =
125;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ /* VDDS1V8 */
+ regulator-name = smps9;
+ regulator-min-microvolt =
180;
+ regulator-max-microvolt =
180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ /* LDO1_OUT -- SDIO */
+ regulator-name = ldo1;
+ regulator-min-microvolt =
180;
+ regulator-max-microvolt =
330;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ /* VDD_RTCIO */
+ /* LDO2 - VDDSHV5, LDO2 also
goes to CAN_PHY_3V3 */
+ regulator-name = ldo2;
+ regulator-min-microvolt
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
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? 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
Re: [PATCH] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
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! 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
Re: [PATCH v2] ARM: omap2: throw the die id into the entropy pool
By the way, if anyone wants to expand on Linus' patch for OMAP, there are several other register fields that could be mixed in, which, based on their names, might vary on a per-chip basis. For example, on OMAP4, the CONTROL_STD_FUSE_OPP* and CONTROL_DPLL_NWELL_TRIM* registers. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Vanilla kernel 3.11.0 boot problem on Pandaboard.
I built the kernel-headers and kernel-image .deb packages using make-kpkg native on the 3.18.3.6 kernel. The package installs created new uEnv.txt, uImage an uInitrd. Do I need an updated uboot for 3.11? [125588.918060] Restarting system. Serial console log === U-Boot SPL 2011.12-2-g1bdc71d (Feb 13 2012 - 18:52:25) Texas Instruments OMAP4430 ES2.3 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2011.12-2-g1bdc71d (Feb 13 2012 - 18:52:25) CPU : OMAP4430 ES2.3 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 SD/MMC found on device 0 reading uEnv.txt 119 bytes read Loaded environment from uEnv.txt Importing environment from mmc ... Running uenvcmd ... reading uImage 4039336 bytes read reading uInitrd 2187985 bytes read ## Booting kernel from Legacy Image at 8000 ... Image Name: kernel 3.11.0-07887-gb409624-dir Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4039272 Bytes = 3.9 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 8160 ... Image Name: ramdisk 3.11.0-07887-gb409624-di Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size:2187921 Bytes = 2.1 MiB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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: Build error in torvalds kernel 3.11 for omap2plus
On Mon, Sep 09, 2013 at 09:31:41PM +0100, Russell King - ARM Linux wrote: On Mon, Sep 09, 2013 at 09:03:48AM -0700, Guenter Roeck wrote: Unfortunately, there are more problems. arch/arm/kernel/built-in.o: In function `ret_fast_syscall': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:42: undefined reference to `user_enter' arch/arm/kernel/built-in.o: In function `no_work_pending': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:77: undefined reference to `user_enter' arch/arm/kernel/built-in.o: In function `vector_swi': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:376: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__dabt_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:365: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__irq_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:375: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__und_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:388: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__pabt_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:662: undefined reference to `user_exit' These are due to ad65782fba50 (context_tracking: Optimize main APIs off case with static key) converting these functions to be inline. No idea what the fix for this is other than reverting the change. Any ideas Frederic? I am all for reverting unless this can be fixed quickly. AFAICS this breaks all arm builds if CONFIG_CONTEXT_TRACKING is enabled. Guenter -- 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: Build error in torvalds kernel 3.11 for omap2plus
On Mon, Sep 09, 2013 at 09:03:48AM -0700, Guenter Roeck wrote: Unfortunately, there are more problems. arch/arm/kernel/built-in.o: In function `ret_fast_syscall': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:42: undefined reference to `user_enter' arch/arm/kernel/built-in.o: In function `no_work_pending': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:77: undefined reference to `user_enter' arch/arm/kernel/built-in.o: In function `vector_swi': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:376: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__dabt_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:365: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__irq_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:375: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__und_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:388: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__pabt_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:662: undefined reference to `user_exit' These are due to ad65782fba50 (context_tracking: Optimize main APIs off case with static key) converting these functions to be inline. No idea what the fix for this is other than reverting the change. Any ideas Frederic? -- 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: Build error in torvalds kernel 3.11 for omap2plus
Adding Kevin Hilman to the CC as he might be interested as well. On Mon, 9 Sep 2013, Guenter Roeck wrote: On Mon, Sep 09, 2013 at 09:31:41PM +0100, Russell King - ARM Linux wrote: On Mon, Sep 09, 2013 at 09:03:48AM -0700, Guenter Roeck wrote: Unfortunately, there are more problems. arch/arm/kernel/built-in.o: In function `ret_fast_syscall': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:42: undefined reference to `user_enter' arch/arm/kernel/built-in.o: In function `no_work_pending': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:77: undefined reference to `user_enter' arch/arm/kernel/built-in.o: In function `vector_swi': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:376: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__dabt_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:365: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__irq_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:375: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__und_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:388: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__pabt_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:662: undefined reference to `user_exit' These are due to ad65782fba50 (context_tracking: Optimize main APIs off case with static key) converting these functions to be inline. No idea what the fix for this is other than reverting the change. Any ideas Frederic? I am all for reverting unless this can be fixed quickly. AFAICS this breaks all arm builds if CONFIG_CONTEXT_TRACKING is enabled. Guenter -- 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] Camera drivers for Nokia RX-51
Hi Pali, On Fri, Sep 06, 2013 at 10:35:18PM +0200, Pali Rohár wrote: On Thursday 04 April 2013 15:11:27 Laurent Pinchart wrote: Hi Sakari, On Thursday 04 April 2013 01:22:28 Sakari Ailus wrote: On Tue, Mar 26, 2013 at 12:07:01AM +0100, Laurent Pinchart wrote: On Sunday 24 March 2013 23:46:01 Sakari Ailus wrote: Pali Rohár wrote: On Thursday 07 March 2013 23:18:27 Sakari Ailus wrote: On Wed, Mar 06, 2013 at 10:44:41PM +0100, Sebastian Reichel wrote: On Wed, Mar 06, 2013 at 09:20:16PM +0100, Pali Rohár wrote: On Wednesday 06 March 2013 21:12:06 Pali Rohár wrote: On Sunday 17 February 2013 20:03:03 Aaro Koskinen wrote: On Sun, Feb 17, 2013 at 04:16:49PM +0100, Pali Rohár wrote: +/* + * arch/arm/mach-omap2/board-rx51-camera.c + * + * Copyright (C) 2008 Nokia Corporation + * + * Contact: Sakari Ailus sakari.ai...@nokia.com + * Tuukka Toivonen tuukka.o.toivo...@nokia.com You should put these people to CC... Just to see if the addresses are still valid (which I doubt). Ok, trying :-) I got Delivery Status Notification (Failure) for both addresses. This is expected. Sakari Ailus hosts some code on github [0], which has the following email address: sakari.ailus+gitori...@retiisi.org.uk I added it to this mail's CC. [0] https://gitorious.org/~sailus Nice to hear people are interested in this. ;-) The primary reason I haven't tried submitting this to mainline is that ARM board code has a bad reputation these days. The N900 does not have yet support for device tree (AFAIK), which also would require a few bits and pieces on the flash driver to work. Also the sensor and lens drivers would need at least some work before being ready for submission to mainline for camera to be usable. Unfortunately I haven't had recently time to work on this. N9(50) support has higher priority for myself. That, too, is pending the DT support for the device. There's indeed more up-to-date code in my repository. Even if it's not too close to mainline anymore it should be a better starting point than the old kernel from MeeGo. URL:https://gitorious.org/omap3camera/pages/Home Hi, this board code is same in your git repository and on meego obs. Patch only adding support for adp1653 driver which is already in upstream kernel. Are there any other problems with this patch to go for upstream? A few more things comes to mind. We depend a little bit on actual board code; it's not only static data. That's the configuration of the external clock from the ISP to the sensor. That should move to the common clock framework so that the ISP registers the clock and the sensor driver can then use it. AFAIR Laurent has done some work on that. Yes. I hope to get the patches in v3.10. Cool! :) The patches have been posted to the linux-media mailing list. If the dependencies make it to v3.10 the OMAP3 ISP patches should get there too. The peculiar detail of the rx51 is that there's a switch on the camera CCP2 bus that selects either sensor (primary or secondary). Both sensors are connected to the same receiver. That isn't properly modelled currently at all, so that's why we have rx51_camera_set_xshutdown(). I guess it'd still work if you only power (i.e. open) either of the devices at a time, though. Have you thought about how we could model that ? Well, the two dependent gpios could be modelled as two independent ones ( for sensor drivers), but setting the state of those gpios could fail, gpio_set_value() still returns void. This isn't pretty perhaps but as a result the initialisation of the secondary sensor to be powered up at the same time will fail since it's in reset: the xshutdown of both sensors is controlled by the same gpio as is the mux (AFAIR). So one N900 camera specific gpio driver would be needed. It'd be a very simple driver. What do you think? I think I'll need to see how the GPIOs are wired up on the board. Hello, after months, what is state of drivers now? I have no choice except to say, much to my regret, that it's not really better than it was half a year ago. That said, I have not taken that off my to-do list. Please keep in mind that the user space interface used by the omap3camd (and implemented by omap34xxcam) is entirely unsupported in the mainline kernel. A wrapper would need to be implemented to mimic the old interface to that binary blob --- all the equivalent functionality is there, albeit much better but quite different. Or
Re: [RFC 0/4] Create infrastructure for running C code from SRAM.
On Sat, Sep 7, 2013 at 9:21 AM, Ard Biesheuvel
ard.biesheu...@linaro.org wrote:
On 6 September 2013 21:32, Russ Dill russ.d...@ti.com wrote:
On Fri, Sep 6, 2013 at 4:12 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
SRAM handling code is in the process of being moved from arch directories
into drivers/misc/sram.c using device tree and genalloc [1] [2]. This RFC
patchset builds on that, including the limitation that the SRAM address is
not known at compile time. Because the SRAM address is not known at compile
time, the code that runs from SRAM must be compiled with -fPIC. Even if
the code were loaded to a fixed virtual address, portions of the code must
often be run with the MMU disabled.
What are you doing about the various gcc utility functions that may be
implicitly called from C code such as memcpy and memset?
That would create a problem. Would '-ffreestanding' be the correct
flag to add?
No, unfortunately, -ffreestanding won't prevent GCC from generating
implicit calls to memzero() et al. These are mainly issued when using
initialized non-POD stack variables so avoiding those might help you
there.
As far as the family of __aeabi_*, I need to add
documentation stating that on ARM, you can't divide, perform modulo,
and can't do 64 bit multiplications. I can then add a make rule that
will grep the symbol lists of .sram sections for ^__aeabi_. Is this
enough?
Well, even printk() needs integer division for its %d/%u modifiers, so
this is really not so easy to achieve.
The general idea is that for each SRAM user (such as an SoC specific
suspend/resume mechanism) to create a group of sections. The section group
is created with a single macro for each user, but end up looking like this:
.sram.am33xx : AT(ADDR(.sram.am33xx) - 0) {
__sram_am33xx_start = .;
*(.sram.am33xx.*)
__sram_am33xx_end = .;
}
Any data or functions that should be copied to SRAM for this use should be
maked with an appropriate __section() attribute. A helper is then added for
translating between the original kernel symbol, and the address of that
function or variable once it has been copied into SRAM. Once control is
passed to a function within the SRAM section grouping, it can access any
variables or functions within that same SRAM section grouping without
translation.
What about the relocations which will need to be fixed up - eg, addresses
in the literal pool, the GOT table contents, etc? You say nothing about
this.
The C code would need to be written so that such accesses do not
occur. From functions that are in the sram text section, only accesses
to other sram sections in their group would be allowed. And above, a
compilation step could be added to make the compilation fail when such
things happen.
The point is that, sadly, GCC is just not very good at generating
relocatable code for embedded targets. Playing with -fvisibility may
result in code that contains fewer dynamic relocations, but you will
always end up with a few that need to be fixed up before the code can
run. Another thing to note is that usually, these relocations can only
be fixed up once, as the addend is overwritten by the fixed-up
address. This means that the code can only run in SRAM, and you should
probably best avoid the module loader machinery as it may clobber the
addends before you get to process them.
One thing that remains implicit in this discussion is that you are
executing from SRAM because DRAM is not available (I presume).
Wouldn't it be better to treat the code that lives in the SRAM as a
completely separate executable? You can generate a PIE executable that
supplies minimal memzero et al, fixup the relocations yourself (look
at the uboot sources for an example of this) and you will be
absolutely sure that the code can run completely autonomously. In
fact, some of this stuff could potentially be reused for other
disjoint execution domains such as TZ secure world.
This is the path I'm going down, but I'm trying to do it without
relocations. I'm following the model of arch/arm/boot/compressed and
generating a relocatable gcc builtin library with weak symbols
containing lib1funcs.S, string.c, ashldi3.S, and some stubs for div0
and the unwind symbols, call in sramlib.o.
I'm then doing an objcopy of the .sramlib section, and the .sram.*
sections into a single object file and performing a link with a linker
script like:
SECTIONS
{
.text : { *(.sramlib) }
OVERLAY ALIGN(32) : NOCROSSREFS
{
.sram.am33xx { *(.sram.am33xx.*) }
.sram.am437x { *(.sram.am437x.*) }
}
}
It produces output without any relocations, but from there I'm a
little fuzzy on how to get the symbols of functions and variables into
the kernel. In the meantime, I'll look into the u-boot methods.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [PATCH] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
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. 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
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
Re: [PATCH] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
On Sep 10, 2013, at 12:45 AM, Koen Kooi k...@dominion.thruhere.net wrote: 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 Ok since you said in above thread you'll rebase the card detect and the regulator fixes , I'll let you do that and drop my drop my hacked mmc1 patch for BBB from my series. 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
