Re: [PATCH v2 05/13] extcon: extcon-class: improve extcon client API
On 04/19/2014 12:52 PM, Aaro Koskinen wrote: Hi, On Mon, Apr 14, 2014 at 01:46:16PM +0200, Robert Baldyga wrote: dev_info(pdev-dev, - OMAP USB OTG controller rev %d.%d (%s, id=%d, vbus=%d)\n, - (rev 4) 0xf, rev 0xf, config-extcon, otg_dev-id, + OMAP USB OTG controller rev %d.%d (id=%d, vbus=%d)\n, + (rev 4) 0xf, rev 0xf, otg_dev-id, otg_dev-vbus); This change is unrelated to the patch and not needed. It's related because we no longer use config-extcon since we have cable-oriented API. We can keep displaying it, but this value is actually meaningless. Best regards Robert Baldyga Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: Add support for the BeagleBoard xM A/B
Tony,
From: Tony Lindgren
* Robert Nelson robertcnel...@gmail.com [140418 16:42]:
On Fri, Apr 18, 2014 at 5:51 PM, Tony Lindgren t...@atomide.com wrote:
* Robert Nelson robertcnel...@gmail.com [140415 08:46]:
Background: i also tried getting this having this fixed in u-boot:
Do we still need to apply this patch then?
Yeah, Tom want's it done in the kernel:
Here's my proposed u-boot patch:
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
and Tom's recommendation:
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Once this hits mainline, i'll submit a patch to u-boot to check for
the presence of this version and drop to the old dtb if not found.
OK applying into omap-for-v3.15/fixes thanks.
Tony
You probably missed fixing below typo before applying this patch.
omap3-beagle-xm-ab.dts breaks without this.
+/ {
+ /* HS USB Port 2 Power enable was inverted with the xM C */
+ hsusb2_power: hsusb2_power_reg {
+ enable-active-high;
};
+};
with regards, pekon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix few omap gpmc regressions when booted with device tree
Hi Tony,
On Tue, Apr 22, 2014 at 2:54 AM, Tony Lindgren t...@atomide.com wrote:
Hi all,
Here are two fixes to GPMC issues I've seen. It seems that we have
few more issues left to solve:
1. The remap of a device with gpmc_cs_remap seems to fail for
a device if it's address specified in the .dts file is
different from the address used by the bootloader
2. There seems to be some timing issues with smc911x where
rsync of larger files and apt-get dist-upgrade can produce
strange errors. This seems to work reliably when booted in
legacy mode.
In what board are you having this issue? The smsc911x driver supports
both SMSC's LAN911x and LAN921x families and I see that we have two
.dtsi files with different timings
(arm/boot/dts/omap-gpmc-smsc{911x,9221}.dtsi).
This is only a wild guess, but maybe your board has a smsc LAN921x
chip but is including omap-gpmc-smsc911x.dtsi on its DTS?
3. The DT mappings of GPMC devices are wrong for most devices
where the ranges property should contain the GPMC partition
size (16, 32, 128 or 256 MB), and the reg property for the
device should only contain the device IO range. So only NOR
should use large values for ranges and IO range, the rest
should use the minimum 16 MB range for GPMC partition, and
0x4 - 0x2 for the IO range. And while patching these
it makes sense to also unify the GPMC ranges being used for
devices.
Pekon, can you take a look at 1 and 2 above?
Then for 3 above, it seems that we cannot safely change
ranges before 1 and 2 are working reliably. Or else we have
patch things twice, once to fix the range sizes, then to
unify the mappings for the range address...
Regards,
Tony
Tony Lindgren (2):
ARM: OMAP2+: Fix oops for GPMC free
ARM: OMAP2+: Fix GPMC remap for devices using an offset
These fixes look good to me.
Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org
arch/arm/mach-omap2/gpmc.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]
* How to boot from NAND using Memory Expander + NAND Cape ? *
- Important: As BOOTSEL values are sampled only at POR, so after changing any
setting on SW2 (DIP switch), disconnect and reconnect all board power supply
(including mini-USB console port) to POR the beaglebone.
- Selection of ECC scheme
for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
- Selection of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape, so first boot via MMC or other sources to flash NAND
device and then switch to SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC- SPI - UART - USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
- For NAND boot following switch settings need to be followed
SW2[ 0] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 1] = ON (SYSBOOT[ 1]==0: -- do -- )
SW2[ 2] = OFF (SYSBOOT[ 2]==1: -- do -- )
SW2[ 3] = OFF (SYSBOOT[ 3]==1: -- do -- )
SW2[ 4] = ON (SYSBOOT[ 4]==0: -- do -- )
SW2[ 8] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 9] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
SW2[10] = ON (SYSBOOT[10]==0: Non Muxed device )
SW2[11] = ON (SYSBOOT[11]==0:-- do -- )
[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2]
http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-bone-memory-cape.dts | 130 ++
arch/arm/boot/dts/am335x-bone.dts | 1 +
arch/arm/boot/dts/am335x-boneblack.dts| 1 +
3 files changed, 132 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts
b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
new file mode 100644
index 000..9c9f6a6
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,130 @@
+/*
+ * Copyright (C) 2014 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.
+ *
+ * This DTS adds supports for capes using GPMC interface to connect external
+ * memory like NAND, NOR Flash to Beaglebone-LT (white) and Beaglebone-Black.
+ */
+
+
+am33xx_pinmux {
+ nand_flash_x16: nand_flash_x16 {
+ pinctrl-single,pins =
+ 0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
+ 0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
+ 0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
+ 0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
+ 0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
+ 0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
+ 0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
+ 0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
+ 0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
+ 0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
+ 0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10
*/
+ 0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11
*/
+ 0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12
*/
+ 0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad13.gpmc_ad13
*/
+ 0x38 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad14.gpmc_ad14
*/
+ 0x3c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad15.gpmc_ad15
*/
+ 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)/*
gpmc_wpn.gpio0_30 */
+ 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_wen.gpmc_wen */
+ 0x9c (MUX_MODE0 | PIN_OUTPUT)
[PATCH v3 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)
*changes v2 - v3* rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap :master merged leftover patches (dra7-evm and am43x-epos-evm fix) from Part-1 series *changes v1 - v2* [PATCH v2 1/2] created new DTS for memory-capes based on following feedbacks http://www.spinics.net/lists/linux-omap/msg104348.html from 'Nishanth Menon n...@ti.com' http://www.spinics.net/lists/linux-omap/msg104447.html from 'Tony Lindgren t...@atomide.com' [PATCH v2 2/2] same as [PATCH v1 1/3] *original v1* This patch-set adds parallel NAND support on following TI platforms - AM335x (am335x-bone LT, am335x-boneblack): disabled by default - AM43xx (am437x-gp-evm) Minal Shah (1): ARM: dts: dra7: add support for parallel NAND flash Pekon Gupta (3): ARM: dts: am335x-bone: add support for beaglebone NAND cape ARM: dts: am437x-gp-evm: add support for parallel NAND flash ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition arch/arm/boot/dts/am335x-bone-memory-cape.dts | 130 ++ arch/arm/boot/dts/am335x-bone.dts | 1 + arch/arm/boot/dts/am335x-boneblack.dts| 1 + arch/arm/boot/dts/am437x-gp-evm.dts | 107 + arch/arm/boot/dts/am43x-epos-evm.dts | 2 +- arch/arm/boot/dts/dra7-evm.dts| 117 +++ arch/arm/boot/dts/dra7.dtsi | 20 7 files changed, 377 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts -- 1.8.5.1.163.gd7aced9 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
(a) By dynamically driving following GPIO pin from software
SPI2_CS0(GPIO) == 0 NAND is selected (default)
SPI2_CS0(GPIO) == 1 eMMC is selected
(b) By statically using Jumper (J89) on the board
(2) As NAND device connnected to this board has page-size=4K and oob-size=224,
So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
NAND boot.
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 107
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..0027ea7 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -81,6 +81,27 @@
0x164 MUX_MODE0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
;
};
+
+ nand_flash_x8: nand_flash_x8 {
+ pinctrl-single,pins =
+ 0x26C(PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
spi2_cs0.gpio/eMMCorNANDsel */
+ 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_wpn.gpmc_wpn */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ ;
+ };
};
i2c0 {
@@ -125,3 +146,89 @@
pinctrl-0 = mmc1_pins;
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
};
+
+elm {
+ status = okay;
+};
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ ti,nand-ecc-opt = bch8;
+ ti,elm-id = elm;
+ nand-bus-width = 8;
+ gpmc,device-width = 1;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 40;
+ gpmc,cs-wr-off-ns = 40;
+ gpmc,adv-on-ns = 0;
+ gpmc,adv-rd-off-ns = 25;
+ gpmc,adv-wr-off-ns = 25;
+ gpmc,we-on-ns = 0;
+ gpmc,we-off-ns = 20;
+ gpmc,oe-on-ns = 3;
+ gpmc,oe-off-ns = 30;
+ gpmc,access-ns = 30;
+ gpmc,rd-cycle-ns = 40;
+ gpmc,wr-cycle-ns = 40;
+ gpmc,wait-on-read = true;
+ gpmc,wait-on-write = true;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,clk-activation-ns = 0;
+ gpmc,wait-monitoring-ns = 0;
+ gpmc,wr-access-ns = 40;
+ gpmc,wr-data-mux-bus-ns = 0;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+* which can be independently programmable. For
+* NAND flash this is equal to size of erase-block */
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+ label = NAND.SPL;
+ reg = 0x 0x0004;
+ };
+ partition@1 {
+ label = NAND.SPL.backup1;
+ reg = 0x0004 0x0004;
+ };
+ partition@2 {
+ label = NAND.SPL.backup2;
+ reg = 0x0008 0x0004;
+ };
+ partition@3 {
+ label = NAND.SPL.backup3;
+ reg = 0x000C 0x0004;
+ };
+
Re: [RFC PATCH 00/11] Embeddable Position Independent Executable
Hi Russ, Am Donnerstag, 24. Oktober 2013, 10:09:12 schrieb Heiko Stübner: Am Dienstag, 17. September 2013, 14:43:26 schrieb Russ Dill: This patch adds support for and demonstrates the usage of an embedded position independent executable (PIE). The goal is to allow the use of C code in situations where carefully written position independent assembly was previously required. As suggested yesterday evening by Kevin Hilman, just adding my 2ct of support. This series looks exactly like the foundation I'll need at some point in the (probably still distant) future to handle suspend on my Rockchip platform - where like in your example stuff like putting the ram into selfrefresh has to be done by the os. just as it came up recently again for me and I couldn't find any newer version, ist this series still on the table? Thanks Heiko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] ARM: OMAP2+: L2 cache: git rid of redundant cache replacement policy setting
L2 cache initialization for OMAP4 redundantly sets the cache policy to Round-Robin. This is not needed since thats the PL310 default anyway. Removing this reduces the number of platform specific aux control settings. Signed-off-by: Sekhar Nori nsek...@ti.com --- arch/arm/mach-omap2/omap4-common.c |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index 1230975..c41ff8b 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -206,16 +206,15 @@ int __init omap_l2_cache_init(void) return -ENOMEM; /* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */ - aux_ctrl = L310_AUX_CTRL_CACHE_REPLACE_RR | - L2C_AUX_CTRL_SHARED_OVERRIDE | + aux_ctrl = L2C_AUX_CTRL_SHARED_OVERRIDE | L310_AUX_CTRL_DATA_PREFETCH | L310_AUX_CTRL_INSTR_PREFETCH; outer_cache.write_sec = omap4_l2c310_write_sec; if (of_have_populated_dt()) - l2x0_of_init(aux_ctrl, 0xcd9f); + l2x0_of_init(aux_ctrl, 0xcf9f); else - l2x0_init(l2cache_base, aux_ctrl, 0xcd9f); + l2x0_init(l2cache_base, aux_ctrl, 0xcf9f); return 0; } -- 1.7.10.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] ARM: OMAP2+: L2 cache: get rid of init call
Get rid of init call to initialize L2 cache.
Instead use the init_early machine hook. This
helps in using the initialization routine across
SoCs without the need of ugly cpu_is_*() checks.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/omap4-common.c | 10 +-
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index d88aff7..ff02973 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -91,6 +91,7 @@ extern void omap3_sync32k_timer_init(void);
extern void omap3_secure_sync32k_timer_init(void);
extern void omap3_gptimer_timer_init(void);
extern void omap4_local_timer_init(void);
+int omap_l2_cache_init(void);
extern void omap5_realtime_timer_init(void);
void omap2420_init_early(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index f14f9ac..b28299b 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -640,6 +640,7 @@ void __init omap4430_init_early(void)
omap44xx_clockdomains_init();
omap44xx_hwmod_init();
omap_hwmod_init_postsetup();
+ omap_l2_cache_init();
omap_clk_soc_init = omap4xxx_dt_clk_init;
}
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index df3f531..1230975 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -196,17 +196,10 @@ static void omap4_l2c310_write_sec(unsigned long val,
unsigned reg)
omap_smc1(smc_op, val);
}
-static int __init omap_l2_cache_init(void)
+int __init omap_l2_cache_init(void)
{
u32 aux_ctrl;
- /*
-* To avoid code running on other OMAPs in
-* multi-omap builds
-*/
- if (!cpu_is_omap44xx())
- return -ENODEV;
-
/* Static mapping, never released */
l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K);
if (WARN_ON(!l2cache_base))
@@ -226,7 +219,6 @@ static int __init omap_l2_cache_init(void)
return 0;
}
-omap_early_initcall(omap_l2_cache_init);
#endif
void __iomem *omap4_get_sar_ram_base(void)
--
1.7.10.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] ARM: OMAP2+: AM43x: L2 cache support
Add support for L2 cache controller (PL310) on AM437x SoC. Signed-off-by: Sekhar Nori nsek...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/io.c|1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 1124155..1fd34d2 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -65,6 +65,7 @@ config SOC_AM43XX select ARCH_HAS_OPP select ARM_GIC select MACH_OMAP_GENERIC + select MIGHT_HAVE_CACHE_L2X0 config SOC_DRA7XX bool TI DRA7XX diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index b28299b..4e2df49 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -609,6 +609,7 @@ void __init am43xx_init_early(void) am43xx_clockdomains_init(); am43xx_hwmod_init(); omap_hwmod_init_postsetup(); + omap_l2_cache_init(); omap_clk_soc_init = am43xx_dt_clk_init; } -- 1.7.10.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] ARM: OMAP2+: AM437x: L2 cache support
This patch series adds L2 cache support for AM437x and does some clean-ups for existing OMAP4 support along the way (no functional changes). On OMAP4 Panda, the Aux control value remains 0x7e47 before and after the series. Tested on OMAP4 Panda and AM437x EPOS EVMs. It is based on RMK's 75 patch series titled l2c series + the patch contained in https://www.mail-archive.com/linux-omap@vger.kernel.org/msg103439.html Sekhar Nori (3): ARM: OMAP2+: L2 cache: get rid of init call ARM: OMAP2+: L2 cache: git rid of redundant cache replacement policy setting ARM: OMAP2+: AM43x: L2 cache support arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/io.c |2 ++ arch/arm/mach-omap2/omap4-common.c | 17 - 4 files changed, 8 insertions(+), 13 deletions(-) -- 1.7.10.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/4] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition
MTD NAND partition for file-system should start at offset=0xA0
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 167dbc8..d09e6fb 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -341,7 +341,7 @@
};
partition@9 {
label = NAND.file-system;
- reg = 0x0080 0x1F60;
+ reg = 0x00A0 0x1F60;
};
};
};
--
1.8.5.1.163.gd7aced9
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] ARM: dts: dra7: add support for parallel NAND flash
From: Minal Shah minalks...@gmail.com
DRA7xx platform has in-build GPMC and ELM h/w engines which can be used
for accessing externel NAND flash device. This patch:
- adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines
- adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm
*Important*
On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch
So following board settings are required for NAND device detection:
SW5.9 (GPMC_WPN) = LOW
SW5.1 (NAND_BOOTn) = HIGH
Signed-off-by: Minal Shah minalks...@gmail.com
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 117 +
arch/arm/boot/dts/dra7.dtsi| 20 +++
2 files changed, 137 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..7b4e6f5 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,37 @@
0x24c (PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
;
};
+
+ nand_flash_x16: nand_flash_x16 {
+ /* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch
+* So NAND flash requires following switch settings:
+* SW5.9 (GPMC_WPN) = LOW
+* SW5.1 (NAND_BOOTn) = HIGH */
+ pinctrl-single,pins =
+ 0x0 (PIN_INPUT | MUX_MODE0)/* gpmc_ad0
*/
+ 0x4 (PIN_INPUT | MUX_MODE0)/* gpmc_ad1
*/
+ 0x8 (PIN_INPUT | MUX_MODE0)/* gpmc_ad2
*/
+ 0xc (PIN_INPUT | MUX_MODE0)/* gpmc_ad3
*/
+ 0x10(PIN_INPUT | MUX_MODE0)/* gpmc_ad4
*/
+ 0x14(PIN_INPUT | MUX_MODE0)/* gpmc_ad5
*/
+ 0x18(PIN_INPUT | MUX_MODE0)/* gpmc_ad6
*/
+ 0x1c(PIN_INPUT | MUX_MODE0)/* gpmc_ad7
*/
+ 0x20(PIN_INPUT | MUX_MODE0)/* gpmc_ad8
*/
+ 0x24(PIN_INPUT | MUX_MODE0)/* gpmc_ad9
*/
+ 0x28(PIN_INPUT | MUX_MODE0)/* gpmc_ad10
*/
+ 0x2c(PIN_INPUT | MUX_MODE0)/* gpmc_ad11
*/
+ 0x30(PIN_INPUT | MUX_MODE0)/* gpmc_ad12
*/
+ 0x34(PIN_INPUT | MUX_MODE0)/* gpmc_ad13
*/
+ 0x38(PIN_INPUT | MUX_MODE0)/* gpmc_ad14
*/
+ 0x3c(PIN_INPUT | MUX_MODE0)/* gpmc_ad15
*/
+ 0xD8(PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0
*/
+ 0xCC(PIN_OUTPUT | MUX_MODE0)/* gpmc_wen
*/
+ 0xB4(PIN_OUTPUT_PULLUP | MUX_MODE0) /* gpmc_csn0
*/
+ 0xC4(PIN_OUTPUT | MUX_MODE0)/*
gpmc_advn_ale */
+ 0xC8(PIN_OUTPUT | MUX_MODE0)/* gpmc_oen_ren
*/
+ 0xD0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
+ ;
+ };
};
i2c1 {
@@ -273,3 +304,89 @@
cpu0 {
cpu0-supply = smps123_reg;
};
+
+elm {
+ status = okay;
+};
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x16;
+ ranges = 0 0 0x0800 0x1000;
+ nand@0,0 {
+ reg = 0 0 0;
+ ti,nand-ecc-opt = bch8;
+ ti,elm-id = elm;
+ nand-bus-width = 16;
+ gpmc,device-width = 2;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 40;
+ gpmc,cs-wr-off-ns = 40;
+ gpmc,adv-on-ns = 0;
+ gpmc,adv-rd-off-ns = 30;
+ gpmc,adv-wr-off-ns = 30;
+ gpmc,we-on-ns = 5;
+ gpmc,we-off-ns = 25;
+ gpmc,oe-on-ns = 2;
+ gpmc,oe-off-ns = 20;
+ gpmc,access-ns = 20;
+ gpmc,wr-access-ns = 40;
+ gpmc,rd-cycle-ns = 40;
+ gpmc,wr-cycle-ns = 40;
+ gpmc,wait-on-read = true;
+ gpmc,wait-on-write = true;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,clk-activation-ns = 0;
+ gpmc,wait-monitoring-ns = 0;
+ gpmc,wr-data-mux-bus-ns = 0;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+* which can be independently programmable. For
+* NAND flash this is equal to size of erase-block */
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+
[PATCH] gpio: omap: implement get_direction
From: Yegor Yefremov yegorsli...@googlemail.com
This patch implements gpio_chip's get_direction() routine, that
lets other drivers get particular GPIOs direction using
struct gpio_desc.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
drivers/gpio/gpio-omap.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..b55bf7b 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -102,6 +102,20 @@ static int omap_gpio_to_irq(struct gpio_chip *chip,
unsigned offset)
return irq_find_mapping(bank-domain, offset);
}
+static int _get_gpio_direction(struct gpio_bank *bank, int gpio)
+{
+ void __iomem *reg = bank-base;
+ u32 l;
+ u32 mask = 1 gpio;
+
+ reg += bank-regs-direction;
+ l = readl_relaxed(reg);
+ if (l mask)
+ return 1;
+
+ return 0;
+}
+
static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int is_input)
{
void __iomem *reg = bank-base;
@@ -936,6 +950,19 @@ static inline void mpuio_init(struct gpio_bank *bank)
/*-*/
+static int gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+ struct gpio_bank *bank;
+ unsigned long flags;
+ int dir;
+
+ bank = container_of(chip, struct gpio_bank, chip);
+ spin_lock_irqsave(bank-lock, flags);
+ dir = _get_gpio_direction(bank, offset);
+ spin_unlock_irqrestore(bank-lock, flags);
+ return dir;
+}
+
static int gpio_input(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank;
@@ -1092,6 +1119,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
*/
bank-chip.request = omap_gpio_request;
bank-chip.free = omap_gpio_free;
+ bank-chip.get_direction = gpio_get_direction;
bank-chip.direction_input = gpio_input;
bank-chip.get = gpio_get;
bank-chip.direction_output = gpio_output;
--
1.7.7
--
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: AM43xx: clk: Change the wdt1 func clk src to per_32k clk
On 04/16/2014 07:14 AM, Lokesh Vutla wrote:
WDT1 module can take one of the below clocks as input functional
clock -
- On-Chip 32K RC Osc [default/reset]
- 32K from PRCM
The On-Chip 32K RC Osc clock is not an accurate clock-source as per
the design/spec, so as a result, for example, timer which supposed
to get expired @60Sec, but will expire somewhere ~@40Sec, which is
not expected by any use-case.
The solution here is to switch the input clock-source to PRCM
generated 32K clock-source during boot-time itself.
This is derived from AM33xx clock file.
I guess this patch should wait until we have a proper solution upstream
for selecting parents based on DT data, unless you have pressing need to
merge this as a temporary hack.
-Tero
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/clk/ti/clk-43xx.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..ae2524e 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -110,9 +110,22 @@ static struct ti_dt_clk am43xx_clks[] = {
int __init am43xx_dt_clk_init(void)
{
+ struct clk *clk1, *clk2;
+
ti_dt_clocks_register(am43xx_clks);
omap2_clk_disable_autoidle_all();
+ /*
+* The On-Chip 32K RC Osc clock is not an accurate clock-source as per
+* the design/spec, so as a result, for example, timer which supposed
+* to get expired @60Sec, but will expire somewhere ~@40Sec, which is
+* not expected by any use-case, so change WDT1 clock source to PRCM
+* 32KHz clock.
+*/
+ clk1 = clk_get_sys(NULL, wdt1_fck);
+ clk2 = clk_get_sys(NULL, clkdiv32k_ick);
+ clk_set_parent(clk1, clk2);
+
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: omap: implement get_direction
Hello Yegor,
On Tue, Apr 22, 2014 at 11:23 AM, yegorsli...@googlemail.com wrote:
From: Yegor Yefremov yegorsli...@googlemail.com
This patch implements gpio_chip's get_direction() routine, that
lets other drivers get particular GPIOs direction using
struct gpio_desc.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
drivers/gpio/gpio-omap.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..b55bf7b 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -102,6 +102,20 @@ static int omap_gpio_to_irq(struct gpio_chip *chip,
unsigned offset)
return irq_find_mapping(bank-domain, offset);
}
+static int _get_gpio_direction(struct gpio_bank *bank, int gpio)
+{
+ void __iomem *reg = bank-base;
+ u32 l;
+ u32 mask = 1 gpio;
+
+ reg += bank-regs-direction;
+ l = readl_relaxed(reg);
+ if (l mask)
+ return 1;
+
+ return 0;
+}
+
You can avoid the if condition here by using return !!(l mask) but
the above code is more clear indeed so is up to you.
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int
is_input)
{
void __iomem *reg = bank-base;
@@ -936,6 +950,19 @@ static inline void mpuio_init(struct gpio_bank *bank)
/*-*/
+static int gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+ struct gpio_bank *bank;
+ unsigned long flags;
+ int dir;
+
+ bank = container_of(chip, struct gpio_bank, chip);
+ spin_lock_irqsave(bank-lock, flags);
+ dir = _get_gpio_direction(bank, offset);
+ spin_unlock_irqrestore(bank-lock, flags);
+ return dir;
+}
+
static int gpio_input(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank;
@@ -1092,6 +1119,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
*/
bank-chip.request = omap_gpio_request;
bank-chip.free = omap_gpio_free;
+ bank-chip.get_direction = gpio_get_direction;
bank-chip.direction_input = gpio_input;
bank-chip.get = gpio_get;
bank-chip.direction_output = gpio_output;
--
1.7.7
--
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: dts: am43x-clock: add tbclk data for ehrpwm.
We need tblclk clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 84 ++
drivers/clk/ti/clk-43xx.c|6 +++
2 files changed, 90 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..869f9a5 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,90 @@
clock-mult = 1;
clock-div = 1;
};
+
+ ehrpwm0_gate_tbclk: ehrpwm0_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 0;
+ reg = 0x0664;
+ };
+
+ ehrpwm0_tbclk: ehrpwm0_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm0_gate_tbclk;
+ };
+
+ ehrpwm1_gate_tbclk: ehrpwm1_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 1;
+ reg = 0x0664;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm1_gate_tbclk;
+ };
+
+ ehrpwm2_gate_tbclk: ehrpwm2_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 2;
+ reg = 0x0664;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm2_gate_tbclk;
+ };
+
+ ehrpwm3_gate_tbclk: ehrpwm3_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 2;
+ reg = 0x0664;
+ };
+
+ ehrpwm3_tbclk: ehrpwm3_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm3_gate_tbclk;
+ };
+
+ ehrpwm4_gate_tbclk: ehrpwm4_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 2;
+ reg = 0x0664;
+ };
+
+ ehrpwm4_tbclk: ehrpwm4_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm4_gate_tbclk;
+ };
+
+ ehrpwm5_gate_tbclk: ehrpwm5_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 2;
+ reg = 0x0664;
+ };
+
+ ehrpwm5_tbclk: ehrpwm5_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm5_gate_tbclk;
+ };
};
prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..5413a6a 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, func_12m_clk, func_12m_clk),
DT_CLK(NULL, vtp_clk_div, vtp_clk_div),
DT_CLK(NULL, usbphy_32khz_clkmux, usbphy_32khz_clkmux),
+ DT_CLK(48300200.ehrpwm, tbclk, ehrpwm0_tbclk),
+ DT_CLK(48302200.ehrpwm, tbclk, ehrpwm1_tbclk),
+ DT_CLK(48304200.ehrpwm, tbclk, ehrpwm2_tbclk),
+ DT_CLK(48306200.ehrpwm, tbclk, ehrpwm0_tbclk),
+ DT_CLK(48308200.ehrpwm, tbclk, ehrpwm1_tbclk),
+ DT_CLK(4830a200.ehrpwm, tbclk, ehrpwm2_tbclk),
{ .node_name = 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: [RFC PATCH 0/5] add gpio_chip_ops to hold GPIO operations
On Tue, Apr 8, 2014 at 8:20 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: So this is an RFC patch-set to add a virtual table to be used by GPIO chip controllers and consist of the following patches: Overall I like this. However I don't want to see any transitional phase. I prefer a BIG fat patch converting everyone and its dog to the new vtable and removing the old function pointers. This can be based on the HEAD of my GPIO devel branch. It may be a good idea to use coccinelle for this refactoring in order not to miss any users. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/11] pinctrl: single: Clear pin interrupts enabled by bootloader
On Fri, Apr 11, 2014 at 1:47 AM, Tony Lindgren t...@atomide.com wrote: Since we set up device wake-up interrupts as pinctrl-single interrupts, we now must use the standard request_irq and related functions to manage them. If the pin interrupts are enabled for some pins at boot, the wake-up events can show up as constantly pending at least on omaps and will hang the system unless the related device driver clears the event at the device. To fix this, let's clear the interrupt flags during init, and print out a warning so the board maintainers can update their drivers to do proper request_irq for the driver specific wake-up events. Cc: Haojian Zhuang haojian.zhu...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Looks clean. Acked-by: Linus Walleij linus.wall...@linaro.org Shall I apply this patch or will you funnel it through ARM SoC due to deps? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: core: Fix gadget for system suspend/resume
Hi Felipe,
Looks like we missed this one. Could you please pick this up for -rc?
Thanks.
cheers,
-roger
On 03/26/2014 11:43 AM, Roger Quadros wrote:
During system resume, if the event buffers are not setup before
the gadget controller starts then we start with invalid context
and this can lead to bus access errors. This is especially true for
platforms that loose the controller context during system suspend.
e.g. AM437x.
The following backtrace was found when the system is suspended
and resumed with g_zero loaded on AM437x-evm (USB cable connected
to host all the while).
[ 120.981506] WARNING: CPU: 0 PID: 1656 at drivers/bus/omap_l3_noc.c:137
l3_interrupt_handler+0x198/0x28c()
[ 120.981514] L3 custom error: MASTER:USB0 WR TARGET:GPMC
[ 120.981638] Modules linked in: g_mass_storage usb_f_mass_storage
libcomposite configfs bufferclass_ti(O) omaplfb(O) cryptodev(O) dwc3
snd_soc_evm snd_soc_omap snd_pe
[ 120.981659] CPU: 0 PID: 1656 Comm: sh Tainted: G O
3.12.10-gc559824 #1
[ 120.981669] Backtrace:
[ 120.981705] [c0017880] (dump_backtrace+0x0/0x10c) from [c0017a1c]
(show_stack+0x18/0x1c)
[ 120.981730] r6:c02819ac r5:0009 r4:ec137cb8 r3:
[ 120.981767] [c0017a04] (show_stack+0x0/0x1c) from [c056c0b0]
(dump_stack+0x20/0x28)
[ 120.981802] [c056c090] (dump_stack+0x0/0x28) from [c0046d08]
(warn_slowpath_common+0x70/0x90)
[ 120.981830] [c0046c98] (warn_slowpath_common+0x0/0x90) from [c0046dcc]
(warn_slowpath_fmt+0x38/0x40)
[ 120.981856] r8:c0855eb0 r7:0002 r6:f1000700 r5:0007 r4:80080003
[ 120.981886] [c0046d94] (warn_slowpath_fmt+0x0/0x40) from [c02819ac]
(l3_interrupt_handler+0x198/0x28c)
[ 120.981900] r3:c0801ab8 r2:c06cb354
[ 120.981936] [c0281814] (l3_interrupt_handler+0x0/0x28c) from
[c007162c] (handle_irq_event_percpu+0x54/0x1b8)
[ 120.981962] [c00715d8] (handle_irq_event_percpu+0x0/0x1b8) from
[c00717c0] (handle_irq_event+0x30/0x40)
[ 120.981993] [c0071790] (handle_irq_event+0x0/0x40) from [c0074058]
(handle_fasteoi_irq+0x74/0x128)
[ 120.982006] r4:ed0056c0 r3:
[ 120.982033] [c0073fe4] (handle_fasteoi_irq+0x0/0x128) from [c0070f34]
(generic_handle_irq+0x28/0x38)
[ 120.982046] r4:002a r3:c0073fe4
[ 120.982085] [c0070f0c] (generic_handle_irq+0x0/0x38) from [c0015560]
(handle_IRQ+0x38/0x8c)
[ 120.982098] r4:c080137c r3:0182
[ 120.982124] [c0015528] (handle_IRQ+0x0/0x8c) from [c00087e0]
(gic_handle_irq+0x30/0x5c)
[ 120.982145] r6:ec137dd0 r5:c07ac480 r4:fa24010c r3:0100
[ 120.982169] [c00087b0] (gic_handle_irq+0x0/0x5c) from [c056fcc0]
(__irq_svc+0x40/0x54)
[ 120.982179] Exception stack(0xec137dd0 to 0xec137e18)
[ 120.982195] 7dc0: a1d3
0004
[ 120.982216] 7de0: a153 ec1d9010 c080de90 ec137e30 c080debc
ed756e44 ec137e2c
[ 120.982232] 7e00: ec137de0 ec137e18 bf1150e4 bf115474 6153
[ 120.982253] r7:ec137e04 r6: r5:6153 r4:bf115474
[ 120.982327] [bf115438] (dwc3_complete+0x0/0x40 [dwc3]) from [c0338f50]
(dpm_complete+0xd4/0x19c)
[ 120.982341] r5:ed756e10 r4:ed756e64
[ 120.982370] [c0338e7c] (dpm_complete+0x0/0x19c) from [c0339034]
(dpm_resume_end+0x1c/0x20)
[ 120.982400] [c0339018] (dpm_resume_end+0x0/0x20) from [c006d4ec]
(suspend_devices_and_enter+0x118/0x33c)
[ 120.982412] r4:c0833da4 r3:
[ 120.982436] [c006d3d4] (suspend_devices_and_enter+0x0/0x33c) from
[c006d928] (pm_suspend+0x218/0x254)
[ 120.982458] [c006d710] (pm_suspend+0x0/0x254) from [c006c594]
(state_store+0x70/0xc0)
[ 120.982478] r6:c057a6cc r5:c06a8320 r4:0003 r3:006d
[ 120.982515] [c006c524] (state_store+0x0/0xc0) from [c0264cc0]
(kobj_attr_store+0x1c/0x28)
[ 120.982546] [c0264ca4] (kobj_attr_store+0x0/0x28) from [c012ccb8]
(sysfs_write_file+0x170/0x1a4)
[ 120.982583] [c012cb48] (sysfs_write_file+0x0/0x1a4) from [c00d17e4]
(vfs_write+0xb8/0x190)
[ 120.982611] [c00d172c] (vfs_write+0x0/0x190) from [c00d1bf8]
(SyS_write+0x44/0x78)
[ 120.982641] [c00d1bb4] (SyS_write+0x0/0x78) from [c0014660]
(ret_fast_syscall+0x0/0x30)
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index d001417..10e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -821,6 +821,7 @@ static void dwc3_complete(struct device *dev)
spin_lock_irqsave(dwc-lock, flags);
+ dwc3_event_buffers_setup(dwc);
switch (dwc-dr_mode) {
case USB_DR_MODE_PERIPHERAL:
case USB_DR_MODE_OTG:
@@ -828,7 +829,6 @@ static void dwc3_complete(struct device *dev)
/* FALLTHROUGH */
case USB_DR_MODE_HOST:
default:
- dwc3_event_buffers_setup(dwc);
break;
}
--
To unsubscribe
Re: [RFC PATCH 0/5] add gpio_chip_ops to hold GPIO operations
Hello Linus, On Tue, Apr 22, 2014 at 1:36 PM, Linus Walleij linus.wall...@linaro.org wrote: On Tue, Apr 8, 2014 at 8:20 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: So this is an RFC patch-set to add a virtual table to be used by GPIO chip controllers and consist of the following patches: Overall I like this. However I don't want to see any transitional phase. I prefer a BIG fat patch converting everyone and its dog to the new vtable and removing the old function pointers. This can be based on the HEAD of my GPIO devel branch. Ok, I was adding a commit per GPIO driver but the patch-set would have been very big (~200 patches). It may be a good idea to use coccinelle for this refactoring in order not to miss any users. Agreed, I was manually searching for users by using grep but I agree that is much safer to use coccinelle for this. I don't have previous experience writing coccinelle semantics patches though so it may take more time than I thought but it is the perfect excuse to finally learn how to do it :-) Thanks a lot and best regards, Javier Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-gpio in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: dts: am43x-clock: add tbclk data for ehrpwm.
On 04/22/2014 01:25 PM, Sourav Poddar wrote:
We need tblclk clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 84 ++
drivers/clk/ti/clk-43xx.c|6 +++
2 files changed, 90 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..869f9a5 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,90 @@
clock-mult = 1;
clock-div = 1;
};
+
+ ehrpwm0_gate_tbclk: ehrpwm0_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 0;
+ reg = 0x0664;
+ };
+
+ ehrpwm0_tbclk: ehrpwm0_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm0_gate_tbclk;
+ };
Why do you use composite-clock type here? I see only add one sub-clock
to the composite, thus the composite part is unused. How about using a
gate-clock type only? Same question applies for the rest of the patch also.
-Tero
+
+ ehrpwm1_gate_tbclk: ehrpwm1_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 1;
+ reg = 0x0664;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm1_gate_tbclk;
+ };
+
+ ehrpwm2_gate_tbclk: ehrpwm2_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 2;
+ reg = 0x0664;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm2_gate_tbclk;
+ };
+
+ ehrpwm3_gate_tbclk: ehrpwm3_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 2;
+ reg = 0x0664;
+ };
+
+ ehrpwm3_tbclk: ehrpwm3_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm3_gate_tbclk;
+ };
+
+ ehrpwm4_gate_tbclk: ehrpwm4_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 2;
+ reg = 0x0664;
+ };
+
+ ehrpwm4_tbclk: ehrpwm4_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm4_gate_tbclk;
+ };
+
+ ehrpwm5_gate_tbclk: ehrpwm5_gate_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-no-wait-gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 2;
+ reg = 0x0664;
+ };
+
+ ehrpwm5_tbclk: ehrpwm5_tbclk {
+ #clock-cells = 0;
+ compatible = ti,composite-clock;
+ clocks = ehrpwm5_gate_tbclk;
+ };
};
prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..5413a6a 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, func_12m_clk, func_12m_clk),
DT_CLK(NULL, vtp_clk_div, vtp_clk_div),
DT_CLK(NULL, usbphy_32khz_clkmux, usbphy_32khz_clkmux),
+ DT_CLK(48300200.ehrpwm, tbclk, ehrpwm0_tbclk),
+ DT_CLK(48302200.ehrpwm, tbclk, ehrpwm1_tbclk),
+ DT_CLK(48304200.ehrpwm, tbclk, ehrpwm2_tbclk),
+ DT_CLK(48306200.ehrpwm, tbclk, ehrpwm0_tbclk),
+ DT_CLK(48308200.ehrpwm, tbclk, ehrpwm1_tbclk),
+ DT_CLK(4830a200.ehrpwm, tbclk, ehrpwm2_tbclk),
{ .node_name = NULL },
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] GPIO OMAP driver changes for v3.16
On Fri, Apr 11, 2014 at 5:03 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
Hello Aaro,
On Thu, Apr 10, 2014 at 11:22 PM, Aaro Koskinen aaro.koski...@iki.fi wrote:
Hi,
On Thu, Apr 10, 2014 at 10:17:44PM +0200, Javier Martinez Canillas wrote:
The same happens also on Nokia 770:
[0.118896] genirq: Setting trigger mode 0 for irq 128 failed
(gpio_irq_type+0x0/0x220)
I don't have those errors when booting on my DM3730 IGEPv2 board but
it seems that for some reason on omap1 __irq_set_trigger() complains
when IRQ_TYPE_NONE is used as a default flag when calling
gpiochip_irqchip_add()
Could you please test the following patch and tell me if your board
still works and makes the errors go away?
Now it complains about mode 8...
[0.118835] genirq: Setting trigger mode 8 for irq 128 failed
(gpio_irq_type
+0x0/0x220)
A.
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 8cc9e91..5bc8aec 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1122,7 +1122,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
ret = gpiochip_irqchip_add(bank-chip, gpio_irq_chip,
irq_base, gpio_irq_handler,
- IRQ_TYPE_NONE);
+ IRQ_TYPE_LEVEL_LOW);
if (ret) {
dev_err(bank-dev, Couldn't add irqchip to gpiochip
%d\n, ret);
Best regards,
Javier
Thanks for testing. Unfortunately I'm out of ideas on why that error
could be shown and I don't have a way to further debug it without an
omap1 board. I wonder why that pr_err() message is shown or why it is
still working when an error happens.
Maybe Linus or Santosh could give us a hint on what is happening here.
Isn't an edge IRQ more apropriate as default then?
The code contains this:
if (!bank-regs-leveldetect0
(type (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
return -EINVAL;
Meaning sometimes the banks don't support level IRQs.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/3] tty/serial: Add GPIOLIB helpers for controlling modem lines
On 10.03.2014 17:45, Richard Genoud wrote:
This patch add some helpers to control modem lines (CTS/RTS/DSR...) via
GPIO.
This will be useful for many boards which have a serial controller that
only handle CTS/RTS pins (or even just RX/TX).
Signed-off-by: Richard Genoud richard.gen...@gmail.com
+
+struct mctrl_gpios {
+ struct gpio_desc *gpio[UART_GPIO_MAX];
+};
+
+static const struct {
+ const char *name;
+ unsigned int mctrl;
+ bool dir_out;
+} mctrl_gpios_desc[UART_GPIO_MAX] = {
+ { cts, TIOCM_CTS, false, },
+ { dsr, TIOCM_DSR, false, },
+ { dcd, TIOCM_CD, false, },
+ { rng, TIOCM_RNG, false, },
+ { rts, TIOCM_RTS, true, },
+ { dtr, TIOCM_DTR, true, },
+ { out1, TIOCM_OUT1, true, },
+ { out2, TIOCM_OUT2, true, },
+};
+
+void mctrl_gpio_set(struct mctrl_gpios *gpios, unsigned int mctrl)
+{
+ enum mctrl_gpio_idx i;
+
+ if (IS_ERR_OR_NULL(gpios))
+ return;
+
+ for (i = 0; i UART_GPIO_MAX; i++)
+ if (!IS_ERR_OR_NULL(gpios-gpio[i])
+ mctrl_gpios_desc[i].dir_out)
+ gpiod_set_value(gpios-gpio[i],
+ !!(mctrl mctrl_gpios_desc[i].mctrl));
+}
+EXPORT_SYMBOL_GPL(mctrl_gpio_set);
+
+struct gpio_desc *mctrl_gpio_to_gpiod(struct mctrl_gpios *gpios,
+ enum mctrl_gpio_idx gidx)
+{
+ if (!IS_ERR_OR_NULL(gpios) !IS_ERR_OR_NULL(gpios-gpio[gidx]))
+ return gpios-gpio[gidx];
+ else
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(mctrl_gpio_to_gpiod);
+
+unsigned int mctrl_gpio_get(struct mctrl_gpios *gpios, unsigned int *mctrl)
+{
+ enum mctrl_gpio_idx i;
+
+ /*
+ * return it unchanged if the structure is not allocated
+ */
+ if (IS_ERR_OR_NULL(gpios))
+ return *mctrl;
+
+ for (i = 0; i UART_GPIO_MAX; i++) {
+ if (!IS_ERR_OR_NULL(gpios-gpio[i])
+ !mctrl_gpios_desc[i].dir_out) {
+ if (gpiod_get_value(gpios-gpio[i]))
+ *mctrl |= mctrl_gpios_desc[i].mctrl;
+ else
+ *mctrl = ~mctrl_gpios_desc[i].mctrl;
+ }
+ }
+
+ return *mctrl;
+}
+EXPORT_SYMBOL_GPL(mctrl_gpio_get);
Should this routine be renamed to msr_gpio_get() or perhaps better to give all
values (inputs and outputs)?
I'm trying to port this approach to omap-serial to implement RS485 switching. I
need to know if RTS is already on or not and set it accordingly.
What would be the best solution for this task using this new API?
Yegor
--
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: OMAPDSS and panel-dpi
On Thu, 2014-04-17 at 19:50 -0700, Tony Lindgren wrote:
vpll2 {
- /* Needed for DSS */
- regulator-name = vdds_dsi;
+ /* Needed for DSS */
+ regulator-name = vdds_dsi;
};
This vpll2 node shouldn't be needed with full DT solution.
Tomi
signature.asc
Description: This is a digitally signed message part
regressions in linux-next?
next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat8 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqa known 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX 7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS 8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C 9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6 12: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2N3afw0TI 13: n900: Boot PASS: http://slexy.org/raw/s21qmT6XCJ 14: pandaboard-es: Boot FAIL: http://slexy.org/raw/s28vlMGdeh 15: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20yHoGHdW 16:sdp2430: Boot PASS: http://slexy.org/raw/s20i8Ir3yn 17:sdp3430: Boot PASS: http://slexy.org/raw/s20t4VTeEB 18:sdp4430: Boot FAIL: http://slexy.org/raw/s21SHcOP01 19: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2qmlRZped TOTAL = 19 boards, Booted Boards = 9, No Boot boards = 10 next-20140417-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Yvz8RRkn 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2JFbaPPVA farm issues. - But peter reports fail as well. 3: am3517-evm: Boot PASS: http://slexy.org/raw/s29h2lXGuw 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20Whu6Qjr 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21jBdk51T 6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2118uUlle known. 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s29I92x0p3 8: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s2GqJbMp7C farm issues 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s2fb7JvizO 10: beaglebone: Boot PASS: http://slexy.org/raw/s2uQNDnOlV 11: craneboard: Boot PASS: http://slexy.org/raw/s2pTk8AgdX 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2r2XdK8XF 13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s213f9wx5p 14: n900: Boot PASS: http://slexy.org/raw/s2SaNcFG85 15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2fR7PoakJ 16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2IMJ75sNc 17:sdp2430: Boot PASS: http://slexy.org/raw/s207NAmPbO 18:sdp3430: Boot PASS: http://slexy.org/raw/s20Yzlg3lU 19:sdp4430: Boot PASS: http://slexy.org/raw/s21eYIZxtI 20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2HIEtrDX9 TOTAL = 20 boards, Booted Boards = 17, No Boot boards = 3 next-20140416-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s20LxN1Qn4 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s202mfovsx 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2IAJlhTFg 4: am37x-evm: Boot PASS: http://slexy.org/raw/s213AOULx7 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s22NCBg38K 6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2IhClBS3N known 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2octtFj30 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20t9axfIr 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s21FvZM0Gz 10: beaglebone: Boot PASS: http://slexy.org/raw/s2119uANhW 11: craneboard: Boot PASS: http://slexy.org/raw/s2FoVFiYaC 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2FJjqu4MU 13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s29X2FBMhu 14: n900: Boot PASS: http://slexy.org/raw/s2AcjThjhw 15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2LF8KsxJw 16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2E2KTBSFY 17:sdp2430: Boot PASS: http://slexy.org/raw/s20HnXbU9M 18:sdp3430: Boot PASS: http://slexy.org/raw/s20OuKg9mw 19:sdp4430: Boot PASS: http://slexy.org/raw/s25V9CJgUB 20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s21WFeZmTd TOTAL = 20 boards, Booted Boards = 18, No Boot boards = 2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAPDSS and panel-dpi
On Fri, 2014-04-18 at 18:43 +0200, Joachim Eastwood wrote: If it does not make sense to set up a generic mode-gpios for the panels, then panel dpi can parse the first two GPIOs for enable and reset. Then we can allow the rest of the array be parsed if needed based on the compatible flag. Looking through the panels in omap2/display-new the most common gpio pins are; backlight, reset and enable. So it makes sense to have enable and reset as properties. Gpio is used for mode setting in: nl8048hl11 and ls037v7dw01. nl8048hl11 has just a qvga gpio, while the other one has no less than 3 mode pins (qvga and 2 scanning direction pins). All these mode pins are set once and then never touched again. Using gpios property for setting up an arbitrary amount of mode pins so like a solution to me. Generic reset gpio handling is a bit problematic, as even if we know what the normal state for the gpio is, we don't know how to use it. How long should it be set to reset-state? How long should be it in the normal-state before we can reset again? How to handle the powers when resetting? We could have some big delays there, which would work for more or less all the panels. It just doesn't feel quite right =). If we need reset and panel specific mode pin handling, I think a separate driver is the cleanest option. Do we have any way to set some gpios to a specified value at boot time via DT, in a fixed manner? So more or less what Tony does in ldp_twl_gpio_setup(). If we could just fix the RESET and QVGA gpios, we could use the panel-dpi just fine, and only handle the enable gpio in the panel driver. Tomi signature.asc Description: This is a digitally signed message part
Re: regressions in linux-next?
On 04/22/2014 04:18 PM, Nishanth Menon wrote: next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat8 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqa known 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX 7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS 8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C 9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6 12: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2N3afw0TI 13: n900: Boot PASS: http://slexy.org/raw/s21qmT6XCJ 14: pandaboard-es: Boot FAIL: http://slexy.org/raw/s28vlMGdeh 15: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20yHoGHdW 16:sdp2430: Boot PASS: http://slexy.org/raw/s20i8Ir3yn 17:sdp3430: Boot PASS: http://slexy.org/raw/s20t4VTeEB 18:sdp4430: Boot FAIL: http://slexy.org/raw/s21SHcOP01 19: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2qmlRZped TOTAL = 19 boards, Booted Boards = 9, No Boot boards = 10 next-20140417-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Yvz8RRkn 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2JFbaPPVA farm issues. - But peter reports fail as well. Yes, 20140417 boot fails for me on am335x-evmsk. What I can see with early printk is that the boot hangs around/after omap-gpio in all cases without any further information. I have checked the diff between 20140407, which was fine on evmsk regarding to omap-gpio and if I revert: d04b76626e94 gpio: omap: convert driver to use gpiolib irqchip am335x-evmsk boots up fine. With that commit in place PandaBoardES boots fine, but evmsk does not. 3: am3517-evm: Boot PASS: http://slexy.org/raw/s29h2lXGuw 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20Whu6Qjr 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21jBdk51T 6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2118uUlle known. 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s29I92x0p3 8: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s2GqJbMp7C farm issues 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s2fb7JvizO 10: beaglebone: Boot PASS: http://slexy.org/raw/s2uQNDnOlV 11: craneboard: Boot PASS: http://slexy.org/raw/s2pTk8AgdX 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2r2XdK8XF 13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s213f9wx5p 14: n900: Boot PASS: http://slexy.org/raw/s2SaNcFG85 15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2fR7PoakJ 16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2IMJ75sNc 17:sdp2430: Boot PASS: http://slexy.org/raw/s207NAmPbO 18:sdp3430: Boot PASS: http://slexy.org/raw/s20Yzlg3lU 19:sdp4430: Boot PASS: http://slexy.org/raw/s21eYIZxtI 20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2HIEtrDX9 TOTAL = 20 boards, Booted Boards = 17, No Boot boards = 3 next-20140416-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s20LxN1Qn4 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s202mfovsx 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2IAJlhTFg 4: am37x-evm: Boot PASS: http://slexy.org/raw/s213AOULx7 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s22NCBg38K 6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2IhClBS3N known 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2octtFj30 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20t9axfIr 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s21FvZM0Gz 10: beaglebone: Boot PASS: http://slexy.org/raw/s2119uANhW 11: craneboard: Boot PASS: http://slexy.org/raw/s2FoVFiYaC 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2FJjqu4MU 13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s29X2FBMhu 14: n900: Boot PASS: http://slexy.org/raw/s2AcjThjhw 15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2LF8KsxJw 16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2E2KTBSFY 17:sdp2430: Boot PASS: http://slexy.org/raw/s20HnXbU9M 18:sdp3430: Boot PASS: http://slexy.org/raw/s20OuKg9mw 19:sdp4430: Boot PASS: http://slexy.org/raw/s25V9CJgUB 20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s21WFeZmTd TOTAL = 20 boards, Booted Boards = 18, No Boot boards = 2 -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] gpio: omap: implement get_direction
From: Yegor Yefremov yegorsli...@googlemail.com
This patch implements gpio_chip's get_direction() routine, that
lets other drivers get particular GPIOs direction using
struct gpio_desc.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
---
Changes:
v2: rework return value calculation
drivers/gpio/gpio-omap.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..fadc45e 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -102,6 +102,17 @@ static int omap_gpio_to_irq(struct gpio_chip *chip,
unsigned offset)
return irq_find_mapping(bank-domain, offset);
}
+static int _get_gpio_direction(struct gpio_bank *bank, int gpio)
+{
+ void __iomem *reg = bank-base;
+ u32 l;
+
+ reg += bank-regs-direction;
+ l = (readl_relaxed(reg) gpio);
+
+ return (l 0x0001);
+}
+
static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int is_input)
{
void __iomem *reg = bank-base;
@@ -936,6 +947,19 @@ static inline void mpuio_init(struct gpio_bank *bank)
/*-*/
+static int gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+ struct gpio_bank *bank;
+ unsigned long flags;
+ int dir;
+
+ bank = container_of(chip, struct gpio_bank, chip);
+ spin_lock_irqsave(bank-lock, flags);
+ dir = _get_gpio_direction(bank, offset);
+ spin_unlock_irqrestore(bank-lock, flags);
+ return dir;
+}
+
static int gpio_input(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank;
@@ -1092,6 +1116,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
*/
bank-chip.request = omap_gpio_request;
bank-chip.free = omap_gpio_free;
+ bank-chip.get_direction = gpio_get_direction;
bank-chip.direction_input = gpio_input;
bank-chip.get = gpio_get;
bank-chip.direction_output = gpio_output;
--
1.7.7
--
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] gpio: omap: implement get_direction
On Tue, Apr 22, 2014 at 12:24 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
Hello Yegor,
On Tue, Apr 22, 2014 at 11:23 AM, yegorsli...@googlemail.com wrote:
From: Yegor Yefremov yegorsli...@googlemail.com
This patch implements gpio_chip's get_direction() routine, that
lets other drivers get particular GPIOs direction using
struct gpio_desc.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
drivers/gpio/gpio-omap.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..b55bf7b 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -102,6 +102,20 @@ static int omap_gpio_to_irq(struct gpio_chip *chip,
unsigned offset)
return irq_find_mapping(bank-domain, offset);
}
+static int _get_gpio_direction(struct gpio_bank *bank, int gpio)
+{
+ void __iomem *reg = bank-base;
+ u32 l;
+ u32 mask = 1 gpio;
+
+ reg += bank-regs-direction;
+ l = readl_relaxed(reg);
+ if (l mask)
+ return 1;
+
+ return 0;
+}
+
You can avoid the if condition here by using return !!(l mask) but
the above code is more clear indeed so is up to you.
Hm, nice trick. I've reworked the calculation in v2.
Yegor
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add support for the BeagleBoard xM A/B
* Gupta, Pekon pe...@ti.com [140421 23:49]: Tony, From: Tony Lindgren * Robert Nelson robertcnel...@gmail.com [140418 16:42]: On Fri, Apr 18, 2014 at 5:51 PM, Tony Lindgren t...@atomide.com wrote: * Robert Nelson robertcnel...@gmail.com [140415 08:46]: Background: i also tried getting this having this fixed in u-boot: Do we still need to apply this patch then? Yeah, Tom want's it done in the kernel: Here's my proposed u-boot patch: http://lists.denx.de/pipermail/u-boot/2014-January/172154.html and Tom's recommendation: http://lists.denx.de/pipermail/u-boot/2014-January/172274.html Once this hits mainline, i'll submit a patch to u-boot to check for the presence of this version and drop to the old dtb if not found. OK applying into omap-for-v3.15/fixes thanks. Tony You probably missed fixing below typo before applying this patch. omap3-beagle-xm-ab.dts breaks without this. Yeah pushed out omap-for-v3.15/fixes-v2 with the missing bracket. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] add gpio_chip_ops to hold GPIO operations
On Tuesday 22 April 2014, Javier Martinez Canillas wrote: Hello Linus, On Tue, Apr 22, 2014 at 1:36 PM, Linus Walleij linus.wall...@linaro.org wrote: On Tue, Apr 8, 2014 at 8:20 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: So this is an RFC patch-set to add a virtual table to be used by GPIO chip controllers and consist of the following patches: Overall I like this. Agreed, it's a very good cleanup. However I don't want to see any transitional phase. I prefer a BIG fat patch converting everyone and its dog to the new vtable and removing the old function pointers. This can be based on the HEAD of my GPIO devel branch. Ok, I was adding a commit per GPIO driver but the patch-set would have been very big (~200 patches). It may be a good idea to use coccinelle for this refactoring in order not to miss any users. Agreed, I was manually searching for users by using grep but I agree that is much safer to use coccinelle for this. I don't have previous experience writing coccinelle semantics patches though so it may take more time than I thought but it is the perfect excuse to finally learn how to do it :-) I'm not a big fan of doing this all at once, but it's not my call here. Just one recommendation: if you can't do an obvious coccinelle patch to do everything at once, use extra patches in the beginning to clean up the code enough to make it work, then have the large patch fully automated. Arnd -- 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] ARM: dts: am335x: update USB DT references
Hi Leigh,
On 16/04/2014 13:26, Leigh Brown wrote:
In ARM: dts: am33xx: correcting dt node unit address for usb, the
usb_ctrl_mod and cppi41dma nodes were updated with the correct register
addresses. However, the dts files that reference these nodes were not
updated, and those devices are no longer being enabled.
This patch corrects the references for the affected dts files.
Thanks for the fix. BTW, why is it a RFC? Do you plan to send an updated
version?
FYI, even with this fix, the BBB still does not have a working MUSB on
3.15-rc2. Have you observed that as well?
Signed-off-by: Leigh Brown le...@solinno.co.uk
If this is a final version, I'll apply it for -rc3.
Thanks,
Benoit
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++--
arch/arm/boot/dts/am335x-evm.dts | 4 ++--
arch/arm/boot/dts/am335x-evmsk.dts| 4 ++--
arch/arm/boot/dts/am335x-igep0033.dtsi| 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index e3f27ec..2e7d932 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -183,7 +183,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -204,7 +204,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 28ae040..77df10d 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -331,7 +331,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -352,7 +352,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ec08f6f..ab23885 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -364,7 +364,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -385,7 +385,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 7063311..5942e7d 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -202,7 +202,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -223,7 +223,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
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 01/11] tty: serial: add missing braces
Hi, On Thu, Mar 20, 2014 at 02:29:57PM -0500, Felipe Balbi wrote: per CodingStyle we should have those braces, no functional changes. Signed-off-by: Felipe Balbi ba...@ti.com Greg, do you want me to refresh and resend this series ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: dwc3: core: Fix gadget for system suspend/resume
Hi, On Tue, Apr 22, 2014 at 03:24:44PM +0300, Roger Quadros wrote: Looks like we missed this one. Could you please pick this up for -rc? see http://marc.info/?l=linux-usbm=139809466025568w=2 , it's already there -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 05/13] extcon: extcon-class: improve extcon client API
On Tue, Apr 22, 2014 at 08:21:35AM +0200, Robert Baldyga wrote: On 04/19/2014 12:52 PM, Aaro Koskinen wrote: Hi, On Mon, Apr 14, 2014 at 01:46:16PM +0200, Robert Baldyga wrote: dev_info(pdev-dev, - OMAP USB OTG controller rev %d.%d (%s, id=%d, vbus=%d)\n, - (rev 4) 0xf, rev 0xf, config-extcon, otg_dev-id, + OMAP USB OTG controller rev %d.%d (id=%d, vbus=%d)\n, + (rev 4) 0xf, rev 0xf, otg_dev-id, otg_dev-vbus); This change is unrelated to the patch and not needed. It's related because we no longer use config-extcon since we have cable-oriented API. We can keep displaying it, but this value is actually meaningless. can you just add some note in the commit log ? while at that, also remove config-extconf from debugging print because it won't contain valid data anymore or something like that. Other than that: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 05/13] extcon: extcon-class: improve extcon client API
Hi, On Tue, Apr 22, 2014 at 08:21:35AM +0200, Robert Baldyga wrote: On 04/19/2014 12:52 PM, Aaro Koskinen wrote: On Mon, Apr 14, 2014 at 01:46:16PM +0200, Robert Baldyga wrote: dev_info(pdev-dev, - OMAP USB OTG controller rev %d.%d (%s, id=%d, vbus=%d)\n, - (rev 4) 0xf, rev 0xf, config-extcon, otg_dev-id, + OMAP USB OTG controller rev %d.%d (id=%d, vbus=%d)\n, + (rev 4) 0xf, rev 0xf, otg_dev-id, otg_dev-vbus); This change is unrelated to the patch and not needed. It's related because we no longer use config-extcon since we have cable-oriented API. We can keep displaying it, but this value is actually meaningless. It's not completely meaningless, as the cable is searched using that name. A. -- 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: regressions in linux-next?
Logs with with DEBUG_LL and early printk below: Thread: http://marc.info/?t=139817273800014r=1w=2 On 04/22/2014 08:18 AM, Nishanth Menon wrote: next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat8 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqa known 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX 7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS 8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C 9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6 looks like my fdt_high was 0x and fdt was at 0x80f8 :( so got stomped all over... Time for me to verify every platform again. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix few omap gpmc regressions when booted with device tree
* Javier Martinez Canillas jav...@dowhile0.org [140421 23:55]:
On Tue, Apr 22, 2014 at 2:54 AM, Tony Lindgren t...@atomide.com wrote:
2. There seems to be some timing issues with smc911x where
rsync of larger files and apt-get dist-upgrade can produce
strange errors. This seems to work reliably when booted in
legacy mode.
In what board are you having this issue? The smsc911x driver supports
both SMSC's LAN911x and LAN921x families and I see that we have two
.dtsi files with different timings
(arm/boot/dts/omap-gpmc-smsc{911x,9221}.dtsi).
This is only a wild guess, but maybe your board has a smsc LAN921x
chip but is including omap-gpmc-smsc911x.dtsi on its DTS?
Yes it seems to have two LAN9220s, so this could be the reason.
I don't think we had the omap-gpmc-smsc9221.dtsi when I added the
timings initially.
This is on a sbc-t3730 that I'm using as a gateway that was behaving
reliably before I upgraded it to DT based booting. It's currently
at v3.13-rc3 something, but I don't think we've much GPMC changes
since then.
I'll try upgrading the kernel today and running some tests with
rsync. Looks like we can also remove quite a bit of duplicate
timing data by using omap-gpmc-smsc9221.dtsi, I'll try something
like the patch below.
In any case, I suggest others run some tests on their GPMC Ethernet
too.
Regards,
Tony
8 --
--- a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
@@ -10,18 +10,6 @@
cpu0-supply = vcc;
};
};
-
- vddvario: regulator-vddvario {
- compatible = regulator-fixed;
- regulator-name = vddvario;
- regulator-always-on;
- };
-
- vdd33a: regulator-vdd33a {
- compatible = regulator-fixed;
- regulator-name = vdd33a;
- regulator-always-on;
- };
};
omap3_pmx_core {
@@ -51,42 +39,18 @@
};
};
+#include omap-gpmc-smsc9221.dtsi
+
gpmc {
ranges = 5 0 0x2c00 0x0100;
- smsc1: ethernet@5,0 {
+ smsc1: ethernet@gpmc {
compatible = smsc,lan9221, smsc,lan9115;
pinctrl-names = default;
pinctrl-0 = smsc1_pins;
interrupt-parent = gpio6;
interrupts = 3 IRQ_TYPE_LEVEL_LOW;
reg = 5 0 0xff;
- bank-width = 2;
- gpmc,mux-add-data;
- gpmc,cs-on-ns = 0;
- gpmc,cs-rd-off-ns = 186;
- gpmc,cs-wr-off-ns = 186;
- gpmc,adv-on-ns = 12;
- gpmc,adv-rd-off-ns = 48;
- gpmc,adv-wr-off-ns = 48;
- gpmc,oe-on-ns = 54;
- gpmc,oe-off-ns = 168;
- gpmc,we-on-ns = 54;
- gpmc,we-off-ns = 168;
- gpmc,rd-cycle-ns = 186;
- gpmc,wr-cycle-ns = 186;
- gpmc,access-ns = 114;
- gpmc,page-burst-access-ns = 6;
- gpmc,bus-turnaround-ns = 12;
- gpmc,cycle2cycle-delay-ns = 18;
- gpmc,wr-data-mux-bus-ns = 90;
- gpmc,wr-access-ns = 186;
- gpmc,cycle2cycle-samecsen;
- gpmc,cycle2cycle-diffcsen;
- vddvario-supply = vddvario;
- vdd33a-supply = vdd33a;
- reg-io-width = 4;
- smsc,save-mac-address;
};
};
--- a/arch/arm/boot/dts/omap3-sb-t35.dtsi
+++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi
@@ -2,20 +2,6 @@
* Common support for CompuLab SB-T35 used on SBC-T3530, SBC-T3517 and
SBC-T3730
*/
-/ {
- vddvario_sb_t35: regulator-vddvario-sb-t35 {
- compatible = regulator-fixed;
- regulator-name = vddvario;
- regulator-always-on;
- };
-
- vdd33a_sb_t35: regulator-vdd33a-sb-t35 {
- compatible = regulator-fixed;
- regulator-name = vdd33a;
- regulator-always-on;
- };
-};
-
omap3_pmx_core {
smsc2_pins: pinmux_smsc2_pins {
pinctrl-single,pins =
@@ -38,27 +24,28 @@
bank-width = 2;
gpmc,mux-add-data;
gpmc,cs-on-ns = 0;
- gpmc,cs-rd-off-ns = 186;
- gpmc,cs-wr-off-ns = 186;
- gpmc,adv-on-ns = 12;
- gpmc,adv-rd-off-ns = 48;
- gpmc,adv-wr-off-ns = 48;
- gpmc,oe-on-ns = 54;
- gpmc,oe-off-ns = 168;
- gpmc,we-on-ns = 54;
- gpmc,we-off-ns = 168;
- gpmc,rd-cycle-ns = 186;
- gpmc,wr-cycle-ns = 186;
- gpmc,access-ns = 114;
- gpmc,page-burst-access-ns = 6;
- gpmc,bus-turnaround-ns = 12;
- gpmc,cycle2cycle-delay-ns = 18;
- gpmc,wr-data-mux-bus-ns = 90;
- gpmc,wr-access-ns = 186;
+ gpmc,cs-rd-off-ns = 42;
+
Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements
On Monday 21 April 2014 11:02 PM, Felipe Balbi wrote: Hi, On Wed, Mar 26, 2014 at 07:04:45PM -0500, Felipe Balbi wrote: this series lets us access the newer registers introduced back in OMAP4 which give us some valid information about the OMAP HSMMC IP like max block size, support for ADMA, support for Retention. Right now, only setting max_blk_size correctly as supporting ADMA and Retention will take a lot of work. Tested on OMAP5 uEVM. Felipe Balbi (5): mmc: host: omap_hsmmc: pass host as an argument mmc: host: omap_hsmmc: add reg_offset field mmc: host: omap_hsmmc: introduce new accessor functions mmc: host: omap_hsmmc: switch over to new accessors mmc: host: omap_hsmmc: set max_blk_size correctly Got mislead by your reply to this series, about the alternative way of reading memory size from CAPA register this has been here for almost a month, any comments ? Do you see any performance impact with this series ? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements
Hi, On Tue, Apr 22, 2014 at 09:00:12PM +0530, Balaji T K wrote: On Monday 21 April 2014 11:02 PM, Felipe Balbi wrote: Hi, On Wed, Mar 26, 2014 at 07:04:45PM -0500, Felipe Balbi wrote: this series lets us access the newer registers introduced back in OMAP4 which give us some valid information about the OMAP HSMMC IP like max block size, support for ADMA, support for Retention. Right now, only setting max_blk_size correctly as supporting ADMA and Retention will take a lot of work. Tested on OMAP5 uEVM. Felipe Balbi (5): mmc: host: omap_hsmmc: pass host as an argument mmc: host: omap_hsmmc: add reg_offset field mmc: host: omap_hsmmc: introduce new accessor functions mmc: host: omap_hsmmc: switch over to new accessors mmc: host: omap_hsmmc: set max_blk_size correctly Got mislead by your reply to this series, about the alternative way of reading memory size from CAPA register sure, we can do that if you prefer, I just felt I wouldn't touch platforms I can't really test :-s this has been here for almost a month, any comments ? Do you see any performance impact with this series ? in the normal case ? no... it helps only with large transfers -- balbi signature.asc Description: Digital signature
Re: regressions in linux-next?
Hello Peter and Nishanth, On Tue, Apr 22, 2014 at 3:29 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On 04/22/2014 04:18 PM, Nishanth Menon wrote: next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat8 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqa known 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX 7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS 8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C 9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6 12: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2N3afw0TI 13: n900: Boot PASS: http://slexy.org/raw/s21qmT6XCJ 14: pandaboard-es: Boot FAIL: http://slexy.org/raw/s28vlMGdeh 15: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20yHoGHdW 16:sdp2430: Boot PASS: http://slexy.org/raw/s20i8Ir3yn 17:sdp3430: Boot PASS: http://slexy.org/raw/s20t4VTeEB 18:sdp4430: Boot FAIL: http://slexy.org/raw/s21SHcOP01 19: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2qmlRZped TOTAL = 19 boards, Booted Boards = 9, No Boot boards = 10 next-20140417-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Yvz8RRkn 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2JFbaPPVA farm issues. - But peter reports fail as well. Yes, 20140417 boot fails for me on am335x-evmsk. What I can see with early printk is that the boot hangs around/after omap-gpio in all cases without any further information. I have checked the diff between 20140407, which was fine on evmsk regarding to omap-gpio and if I revert: d04b76626e94 gpio: omap: convert driver to use gpiolib irqchip am335x-evmsk boots up fine. With that commit in place PandaBoardES boots fine, but evmsk does not. I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. Thanks a lot and best regards, Javier 3: am3517-evm: Boot PASS: http://slexy.org/raw/s29h2lXGuw 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20Whu6Qjr 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21jBdk51T 6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2118uUlle known. 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s29I92x0p3 8: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s2GqJbMp7C farm issues 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s2fb7JvizO 10: beaglebone: Boot PASS: http://slexy.org/raw/s2uQNDnOlV 11: craneboard: Boot PASS: http://slexy.org/raw/s2pTk8AgdX 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2r2XdK8XF 13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s213f9wx5p 14: n900: Boot PASS: http://slexy.org/raw/s2SaNcFG85 15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2fR7PoakJ 16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2IMJ75sNc 17:sdp2430: Boot PASS: http://slexy.org/raw/s207NAmPbO 18:sdp3430: Boot PASS: http://slexy.org/raw/s20Yzlg3lU 19:sdp4430: Boot PASS: http://slexy.org/raw/s21eYIZxtI 20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2HIEtrDX9 TOTAL = 20 boards, Booted Boards = 17, No Boot boards = 3 next-20140416-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s20LxN1Qn4 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s202mfovsx 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2IAJlhTFg 4: am37x-evm: Boot PASS: http://slexy.org/raw/s213AOULx7 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s22NCBg38K 6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2IhClBS3N known 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2octtFj30 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20t9axfIr 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s21FvZM0Gz 10: beaglebone: Boot PASS: http://slexy.org/raw/s2119uANhW 11: craneboard: Boot PASS: http://slexy.org/raw/s2FoVFiYaC 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2FJjqu4MU 13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s29X2FBMhu 14: n900: Boot PASS: http://slexy.org/raw/s2AcjThjhw 15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2LF8KsxJw 16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2E2KTBSFY 17:sdp2430: Boot PASS: http://slexy.org/raw/s20HnXbU9M 18:sdp3430: Boot PASS: http://slexy.org/raw/s20OuKg9mw 19:sdp4430: Boot PASS: http://slexy.org/raw/s25V9CJgUB 20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw
Re: [PATCH 11/11] pinctrl: single: Clear pin interrupts enabled by bootloader
* Linus Walleij linus.wall...@linaro.org [140422 04:55]: On Fri, Apr 11, 2014 at 1:47 AM, Tony Lindgren t...@atomide.com wrote: Since we set up device wake-up interrupts as pinctrl-single interrupts, we now must use the standard request_irq and related functions to manage them. If the pin interrupts are enabled for some pins at boot, the wake-up events can show up as constantly pending at least on omaps and will hang the system unless the related device driver clears the event at the device. To fix this, let's clear the interrupt flags during init, and print out a warning so the board maintainers can update their drivers to do proper request_irq for the driver specific wake-up events. Cc: Haojian Zhuang haojian.zhu...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Looks clean. Acked-by: Linus Walleij linus.wall...@linaro.org Shall I apply this patch or will you funnel it through ARM SoC due to deps? No deps except boards hanging without it.. Please feel free to take this one, prererrably as a fix for the -rc series if no objections. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] dma: edma: Fixes for cyclic (audio) operation
On Mon, Apr 14, 2014 at 02:41:55PM +0300, Peter Ujfalusi wrote: Hi, Changes since v2: - Dropped patch 10 from v2 (simplify direction configuration...) - Dropped the channel priority related patches since we are going to go via different route for configuring the priority. - Added ACK from Joel for the patches since they are not changed since v2 Changes since v1: - ASoC patches removed - Comments from Andriy Shevchenko addressed - patch added to fix cases when src/dst_maxburst is set to 0 The series contains now only: Support for DMA pause/resume in cyclic mode device_slave_caps callback and DMA_CYCLIC flag correction. While debugging the edma to get things sorted out I noticed that the debug was too verbose and the important information was hidden even when the we did not asked for verbose dmaengine debug. I have included some debug cleanups for the edma dmaengine driver also. Applied all, expect 9th one! -- ~Vinod Regards, Peter --- Peter Ujfalusi (10): platform_data: edma: Be precise with the paRAM struct arm: common: edma: Save the number of event queues/TCs dmaengine: edma: Correct the handling of src/dst_maxburst == 0 dmaengine: edma: Add support for DMA_PAUSE/RESUME operation dmaengine: edma: Set DMA_CYCLIC capability flag dmaengine: edma: Implement device_slave_caps callback dmaengine: edma: Reduce debug print verbosity for non verbose debugging dmaengine: edma: Prefix debug prints where the text were identical in prep callbacks dmaengine: edma: Add channel number to debug prints dmaengine: edma: Print the direction value as well when it is not supported arch/arm/common/edma.c | 4 ++ drivers/dma/edma.c | 87 ++ include/linux/platform_data/edma.h | 18 3 files changed, 83 insertions(+), 26 deletions(-) -- 1.9.2 -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dmaengine: edma: Add DMA memcpy support
On Fri, Apr 18, 2014 at 09:50:33PM -0500, Joel Fernandes wrote: We add DMA memcpy support to EDMA driver. Successful tests performed using dmatest kernel module. Copy alignment is set to DMA_SLAVE_BUSWIDTH_4_BYTES and users must ensure length is aligned so that copy is performed fully. Applied, thanks -- ~Vinod -- 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] [FIX] dmaengine: virt-dma: Free descriptor after callback
On Fri, Apr 18, 2014 at 11:34:50AM -0500, Joel Fernandes wrote: On 04/18/2014 03:50 AM, Russell King - ARM Linux wrote: On Thu, Apr 17, 2014 at 07:56:50PM -0500, Joel Fernandes wrote: Free the vd (virt descriptor) after the callback is called. In EDMA driver atleast which uses virt-dma, we make use of the desc during the callback and if its dangerously freed before the callback is called. I also noticed this in omap-dma dmaengine driver. You've missed the vital bit of information: why do you make use of the descriptor afterwards? You shouldn't. omap-dma doesn't either. Once clients submit their request to DMA engine, they must not hold any kind of reference to the descriptor other than the cookie. Sorry, I confused edma/omap-dma callbacks for virt dma callbacks. Anyway, I think there is still a chance in edma that we refer to the echan-edesc pointer later on after virt-dma calls the free (in edma_execute), so I'll just NULL that out to be safe and submit a patch. Yes, that would be the right way :) While looking at this, I see it is not called out specfically in documentation, will update that as well -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] ARM: OMAP2+: AM437x: L2 cache support
On Tuesday 22 April 2014 04:28 AM, Sekhar Nori wrote: This patch series adds L2 cache support for AM437x and does some clean-ups for existing OMAP4 support along the way (no functional changes). On OMAP4 Panda, the Aux control value remains 0x7e47 before and after the series. Tested on OMAP4 Panda and AM437x EPOS EVMs. It is based on RMK's 75 patch series titled l2c series + the patch contained in https://www.mail-archive.com/linux-omap@vger.kernel.org/msg103439.html Sekhar Nori (3): ARM: OMAP2+: L2 cache: get rid of init call ARM: OMAP2+: L2 cache: git rid of redundant cache replacement policy setting ARM: OMAP2+: AM43x: L2 cache support For the whole series, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- 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: OMAP5: Switch to THUMB mode if needed on secondary CPU
On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This seems to be because the CPU is in ARM mode once the ROM hands over control to the kernel. Switch to THUMB mode if required once the kernel is control of secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on entry so this is not required and SMP boot works as is. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Nishanth Menon n...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Joel Fernandes jo...@ti.com --- arch/arm/mach-omap2/omap-headsmp.S |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 75e9295..1809dce 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -1,7 +1,7 @@ /* * Secondary CPU startup routine source file. * - * Copyright (C) 2009 Texas Instruments, Inc. + * Copyright (C) 2014 Texas Instruments, Inc. * * Author: * Santosh Shilimkar santosh.shilim...@ti.com @@ -28,9 +28,13 @@ * code. This routine also provides a holding flag into which * secondary core is held until we're ready for it to initialise. * The primary core will update this flag using a hardware -+ * register AuxCoreBoot0. + * register AuxCoreBoot0. */ ENTRY(omap5_secondary_startup) +.arm +THUMB( adr r9, BSYM(wait) ) @ CPU may be entered in ARM mode. +THUMB( bx r9 ) @ If this is a Thumb-2 kernel, +THUMB( .thumb ) @ switch to Thumb now. wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 ldr r0, [r2] mov r0, r0, lsr #5 -- 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: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
On Tuesday 22 April 2014 02:31 PM, Joel Fernandes wrote: On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This seems to be because the CPU is in ARM mode once the ROM hands over control to the kernel. Switch to THUMB mode if required once the kernel is control of secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on entry so this is not required and SMP boot works as is. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Nishanth Menon n...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Joel Fernandes jo...@ti.com --- arch/arm/mach-omap2/omap-headsmp.S |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) Looks fine to me .. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: Typo s/interrupts-names/interrupt-names/g
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Srinivas Kandagatla srinivas.kandaga...@st.com
Cc: linux-omap@vger.kernel.org
Cc: ker...@stlinux.com
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/boot/dts/am33xx.dtsi |4 ++--
arch/arm/boot/dts/am4372.dtsi |4 ++--
arch/arm/boot/dts/stih415-pinctrl.dtsi | 10 +-
arch/arm/boot/dts/stih416-pinctrl.dtsi | 10 +-
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 07f283c20eb1..cb6811e5ae5a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -802,7 +802,7 @@
0x4600 0x40;
reg-names = mpu, dat;
interrupts = 80, 81;
- interrupts-names = tx, rx;
+ interrupt-names = tx, rx;
status = disabled;
dmas = edma 8,
edma 9;
@@ -816,7 +816,7 @@
0x4640 0x40;
reg-names = mpu, dat;
interrupts = 82, 83;
- interrupts-names = tx, rx;
+ interrupt-names = tx, rx;
status = disabled;
dmas = edma 10,
edma 11;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 36d523a26831..d1f8707ff1df 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -691,7 +691,7 @@
0x4600 0x40;
reg-names = mpu, dat;
interrupts = 80, 81;
- interrupts-names = tx, rx;
+ interrupt-names = tx, rx;
status = disabled;
dmas = edma 8,
edma 9;
@@ -705,7 +705,7 @@
0x4640 0x40;
reg-names = mpu, dat;
interrupts = 82, 83;
- interrupts-names = tx, rx;
+ interrupt-names = tx, rx;
status = disabled;
dmas = edma 10,
edma 11;
diff --git a/arch/arm/boot/dts/stih415-pinctrl.dtsi
b/arch/arm/boot/dts/stih415-pinctrl.dtsi
index f09fb10a3791..81df870e5ee6 100644
--- a/arch/arm/boot/dts/stih415-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih415-pinctrl.dtsi
@@ -49,7 +49,7 @@
reg = 0xfe61f080 0x4;
reg-names = irqmux;
interrupts = GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH;
- interrupts-names = irqmux;
+ interrupt-names = irqmux;
ranges = 0 0xfe61 0x5000;
PIO0: gpio@fe61 {
@@ -187,7 +187,7 @@
reg = 0xfee0f080 0x4;
reg-names = irqmux;
interrupts = GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH;
- interrupts-names = irqmux;
+ interrupt-names = irqmux;
ranges = 0 0xfee0 0x8000;
PIO5: gpio@fee0 {
@@ -282,7 +282,7 @@
reg = 0xfe82f080 0x4;
reg-names = irqmux;
interrupts = GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH;
- interrupts-names = irqmux;
+ interrupt-names = irqmux;
ranges = 0 0xfe82 0x8000;
PIO13: gpio@fe82 {
@@ -423,7 +423,7 @@
reg = 0xfd6bf080 0x4;
reg-names = irqmux;
interrupts = GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH;
- interrupts-names = irqmux;
+ interrupt-names = irqmux;
ranges = 0 0xfd6b 0x3000;
PIO100: gpio@fd6b {
@@ -460,7 +460,7 @@
reg = 0xfd33f080 0x4;
reg-names = irqmux;
interrupts = GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH;
- interrupts-names = irqmux;
+ interrupt-names = irqmux;
ranges = 0 0xfd33 0x5000;
PIO103: gpio@fd33 {
diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi
b/arch/arm/boot/dts/stih416-pinctrl.dtsi
index aeea304086eb..250d5ecc951e 100644
--- a/arch/arm/boot/dts/stih416-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih416-pinctrl.dtsi
@@ -53,7 +53,7 @@
Re: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
On Tue, Apr 22, 2014 at 1:31 PM, Joel Fernandes jo...@ti.com wrote: On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU Did you mean THUMB2? omap2plus_defconfig works today with CONFIG_ARM_THUMB enabled.. (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This seems to be because the CPU is in ARM mode once the ROM hands over control to the kernel. Switch to THUMB mode if required once the kernel is control of secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on entry so this is not required and SMP boot works as is. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Nishanth Menon n...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Joel Fernandes jo...@ti.com --- arch/arm/mach-omap2/omap-headsmp.S |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 75e9295..1809dce 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -1,7 +1,7 @@ /* * Secondary CPU startup routine source file. * - * Copyright (C) 2009 Texas Instruments, Inc. + * Copyright (C) 2014 Texas Instruments, Inc. 2009-2014 * * Author: * Santosh Shilimkar santosh.shilim...@ti.com @@ -28,9 +28,13 @@ * code. This routine also provides a holding flag into which * secondary core is held until we're ready for it to initialise. * The primary core will update this flag using a hardware -+ * register AuxCoreBoot0. + * register AuxCoreBoot0. spurious change? */ ENTRY(omap5_secondary_startup) +.arm +THUMB( adr r9, BSYM(wait) ) @ CPU may be entered in ARM mode. +THUMB( bx r9 ) @ If this is a Thumb-2 kernel, +THUMB( .thumb ) @ switch to Thumb now. wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 ldr r0, [r2] mov r0, r0, lsr #5 -- 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
[PATCH] ARM: dts: am437x-gp-evm: Boot fixes
This patch, along with patch here [1], fixes boot for am437x-gp-evm. The bootloader configures gpio5_7 to control the DDR3 termination regulator, the linked patch prevents that gpio bank from being reset and losing the previously configured state, and this patch binds the gpio to a regulator so the kernel is aware of the state of the gpio. [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg102941.html Dave Gerlach (1): ARM: dts: am437x-gp-evm: Add vtt_fixed regulator arch/arm/boot/dts/am437x-gp-evm.dts | 11 +++ 1 file changed, 11 insertions(+) -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: am437x-gp-evm: Add vtt_fixed regulator
The VTT regulator for DDR3 termination on the am437x-gp-evm is
controlled by a gpio. It is configured by the bootloader so here we
define an always-on, fixed voltage regulator to hold the gpio.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index a055f7f..e68d12c 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -27,6 +27,17 @@
enable-active-high;
};
+ vtt_fixed: fixedregulator-vtt {
+ compatible = regulator-fixed;
+ regulator-name = vtt_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ regulator-boot-on;
+ enable-active-high;
+ gpio = gpio5 7 GPIO_ACTIVE_HIGH;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = ecap0 0 5 PWM_POLARITY_INVERTED;
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am437x-gp-evm: Add vtt_fixed regulator
On 04/22/2014 01:52 PM, Dave Gerlach wrote:
The VTT regulator for DDR3 termination on the am437x-gp-evm is
controlled by a gpio. It is configured by the bootloader so here we
define an always-on, fixed voltage regulator to hold the gpio.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index a055f7f..e68d12c 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -27,6 +27,17 @@
enable-active-high;
};
+ vtt_fixed: fixedregulator-vtt {
Would you like to consider any explicit pinctrl here?
+ compatible = regulator-fixed;
+ regulator-name = vtt_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ regulator-boot-on;
+ enable-active-high;
+ gpio = gpio5 7 GPIO_ACTIVE_HIGH;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = ecap0 0 5 PWM_POLARITY_INVERTED;
Do we still need https://patchwork.kernel.org/patch/3871201/ (prevent
hwmod from resetting GPIO5) ?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am437x-gp-evm: Boot fixes
* Dave Gerlach d-gerl...@ti.com [140422 11:52]: This patch, along with patch here [1], fixes boot for am437x-gp-evm. The bootloader configures gpio5_7 to control the DDR3 termination regulator, the linked patch prevents that gpio bank from being reset and losing the previously configured state, and this patch binds the gpio to a regulator so the kernel is aware of the state of the gpio. [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg102941.html Setting up the GPIO regulator makes sense to me. But the hack in the link above is potentially a nasty time bomb for anybody trying to use GPIO bank 5 on that board. What tests have been done that the GPIO bank behaves properly when it's not reset? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regressions in linux-next?
On Apr 22, Javier Martinez Canillas wrote: On Tue, Apr 22, 2014 at 3:29 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On 04/22/2014 04:18 PM, Nishanth Menon wrote: next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat8 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqa known 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX 7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS 8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C 9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6 12: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2N3afw0TI 13: n900: Boot PASS: http://slexy.org/raw/s21qmT6XCJ 14: pandaboard-es: Boot FAIL: http://slexy.org/raw/s28vlMGdeh 15: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20yHoGHdW 16:sdp2430: Boot PASS: http://slexy.org/raw/s20i8Ir3yn 17:sdp3430: Boot PASS: http://slexy.org/raw/s20t4VTeEB 18:sdp4430: Boot FAIL: http://slexy.org/raw/s21SHcOP01 19: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2qmlRZped TOTAL = 19 boards, Booted Boards = 9, No Boot boards = 10 next-20140417-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Yvz8RRkn 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2JFbaPPVA farm issues. - But peter reports fail as well. Yes, 20140417 boot fails for me on am335x-evmsk. What I can see with early printk is that the boot hangs around/after omap-gpio in all cases without any further information. I have checked the diff between 20140407, which was fine on evmsk regarding to omap-gpio and if I revert: d04b76626e94 gpio: omap: convert driver to use gpiolib irqchip am335x-evmsk boots up fine. With that commit in place PandaBoardES boots fine, but evmsk does not. I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. I've tested 20140422 -next on a Beaglebone black board with a custom gpio-keys cape and it seems to be working fine. All the gpio are registered, but there are some suspicious messages: # dmesg | grep gpio gpiochip_add: registered GPIOs 0 to 31 on device: gpio gpiochip_add: registered GPIOs 32 to 63 on device: gpio gpiochip_add: registered GPIOs 64 to 95 on device: gpio gpiochip_add: registered GPIOs 96 to 127 on device: gpio of_get_named_gpiod_flags: can't parse gpios property of node '/fixedregulator@0[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@44e09000[0]' of_get_named_gpiod_flags exited with status 0 of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@4806[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@481d8000[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@481d8000[0]' Regards, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
On my DRA7 system, when the kernel is built in Thumb-2 mode, the secondary CPU (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This seems to be because the CPU is in ARM mode once the ROM hands over control to the kernel. Switch to Thumb-2 mode if required once the kernel is control of secondary CPU. On OMAP4 on the other hand, it appears to be in Thumb-2 mode on entry so this is not required and SMP boot works as is. Also corrected a spurious '+' and updated copyright information. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Nishanth Menon n...@ti.com Cc: Tony Lindgren t...@atomide.com Tested-by: Nishanth Menon n...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Joel Fernandes jo...@ti.com --- arch/arm/mach-omap2/omap-headsmp.S |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 75e9295..40c5d5f 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -1,7 +1,7 @@ /* * Secondary CPU startup routine source file. * - * Copyright (C) 2009 Texas Instruments, Inc. + * Copyright (C) 2009-2014 Texas Instruments, Inc. * * Author: * Santosh Shilimkar santosh.shilim...@ti.com @@ -28,9 +28,13 @@ * code. This routine also provides a holding flag into which * secondary core is held until we're ready for it to initialise. * The primary core will update this flag using a hardware -+ * register AuxCoreBoot0. + * register AuxCoreBoot0. */ ENTRY(omap5_secondary_startup) +.arm +THUMB( adr r9, BSYM(wait) ) @ CPU may be entered in ARM mode. +THUMB( bx r9 ) @ If this is a Thumb-2 kernel, +THUMB( .thumb ) @ switch to Thumb now. wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 ldr r0, [r2] mov r0, r0, lsr #5 -- 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: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
On 04/22/2014 01:47 PM, Nishanth Menon wrote: On Tue, Apr 22, 2014 at 1:31 PM, Joel Fernandes jo...@ti.com wrote: On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU Did you mean THUMB2? omap2plus_defconfig works today with CONFIG_ARM_THUMB enabled.. ARM_THUMB is for user binaries though, not kernel. But yeah I should reword the commit message to use Thumb-2. I'll do that. (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This seems to be because the CPU is in ARM mode once the ROM hands over control to the kernel. Switch to THUMB mode if required once the kernel is control of secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on entry so this is not required and SMP boot works as is. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Nishanth Menon n...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Joel Fernandes jo...@ti.com --- arch/arm/mach-omap2/omap-headsmp.S |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 75e9295..1809dce 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -1,7 +1,7 @@ /* * Secondary CPU startup routine source file. * - * Copyright (C) 2009 Texas Instruments, Inc. + * Copyright (C) 2014 Texas Instruments, Inc. 2009-2014 Sure. * * Author: * Santosh Shilimkar santosh.shilim...@ti.com @@ -28,9 +28,13 @@ * code. This routine also provides a holding flag into which * secondary core is held until we're ready for it to initialise. * The primary core will update this flag using a hardware -+ * register AuxCoreBoot0. + * register AuxCoreBoot0. spurious change? The + is spurious, I was trying to correct that. Will update commit message in v2. 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 v2 01/13] Documentation: add extcon devicetree bindings
On Mon, Apr 14, 2014 at 01:46:12PM +0200, Robert Baldyga wrote:
That's quite some CC list you've got there, and the mail seems a bit
corrupted too (it confused my MUA).
This patch adds extcon devicetree bindings. Documentation describes in general
client and provider bindings, and contains detailed desctiprion of bindings
for each extcon provider.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
.../devicetree/bindings/extcon/extcon-adc-jack.txt | 60 +++
.../devicetree/bindings/extcon/extcon-arizona.txt | 47 +++
.../devicetree/bindings/extcon/extcon-bindings.txt | 36 +++
.../devicetree/bindings/extcon/extcon-gpio.txt | 63
.../devicetree/bindings/extcon/extcon-max14577.txt | 49 +++
.../devicetree/bindings/extcon/extcon-max77693.txt | 56 +
.../devicetree/bindings/extcon/extcon-max8997.txt | 49 +++
.../devicetree/bindings/extcon/extcon-palmas.txt | 37 ++--
This is creating device tree bindings for MFD components as devices when
those MFD components aren't well isolated from the rest of the device.
If we need to add extcon bindings the device should have the flexibility
to decide where to add the properties, and really things should be set
up so there's less duplication in the documentation.
+The following is the list of cables detected by the controller. Each
+cable is assigned an identifier and client nodes use this identifies
+to specify the cable which they are interested in.
+
+ Cable ID
+
+
+ Mechanical 0
+ Microphone 1
+ Headphone 2
+ Line-out 3
+
+Example 1: An example of a extcon controller node is listed below.
+
+ extcon: arizona-extcon {
The above doesn't entirely reflect what the hardware is capable of doing
- it reflects the default software configuration for the device but it's
got a wider feature set.
signature.asc
Description: Digital signature
Re: [PATCH] ARM: dts: am437x-gp-evm: Boot fixes
On 04/22/2014 02:01 PM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [140422 11:52]: This patch, along with patch here [1], fixes boot for am437x-gp-evm. The bootloader configures gpio5_7 to control the DDR3 termination regulator, the linked patch prevents that gpio bank from being reset and losing the previously configured state, and this patch binds the gpio to a regulator so the kernel is aware of the state of the gpio. [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg102941.html Setting up the GPIO regulator makes sense to me. But the hack in the link above is potentially a nasty time bomb for anybody trying to use GPIO bank 5 on that board. What tests have been done that the GPIO bank behaves properly when it's not reset? We've been using this configuration on this board for a while without any apparent issues. Also, am335x-evmsk already uses the same idea for the VTT regulator on board from commit 6046adb6ad701026c10adeac8d6a4138895f12e5 [ARM: dts: am335x-evmsk: Do not reset gpio0] and I am unaware of any issues with that either. Regards, Dave Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am437x-gp-evm: Add vtt_fixed regulator
On 04/22/2014 01:58 PM, Nishanth Menon wrote:
On 04/22/2014 01:52 PM, Dave Gerlach wrote:
The VTT regulator for DDR3 termination on the am437x-gp-evm is
controlled by a gpio. It is configured by the bootloader so here we
define an always-on, fixed voltage regulator to hold the gpio.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index a055f7f..e68d12c 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -27,6 +27,17 @@
enable-active-high;
};
+ vtt_fixed: fixedregulator-vtt {
Would you like to consider any explicit pinctrl here?
Yes, it's a good idea for me to add that in for next version.
+ compatible = regulator-fixed;
+ regulator-name = vtt_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ regulator-boot-on;
+ enable-active-high;
+ gpio = gpio5 7 GPIO_ACTIVE_HIGH;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = ecap0 0 5 PWM_POLARITY_INVERTED;
Do we still need https://patchwork.kernel.org/patch/3871201/ (prevent
hwmod from resetting GPIO5) ?
Yes, without preventing the reset boot still hangs.
--
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/dts: am335x-evmsk enable display and lcd panel support
Add the necessary nodes to enable the LCD controller and the
LCD panel that is attached to the Texas Instruments AM335x
EVMSK platform. Also setup the necessary pin mux within the
DT file to drive the LCD connector and add the correct
pinmux settings for the lcd pins to be configured to when
the SoC goes into sleep state for the minimum power
consumption.
For the sleep mode LCD pin settings, MUX_MODE7 is chosen as
this corresponds to switching the pins into input GPIO's with
an internal pulldown. Which has been determined to offer the
lowest power solution vs leaving the pins configured in LCD
mode.
Signed-off-by: Darren Etheridge detheri...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 105 +
1 file changed, 105 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ec08f6f..a5e1ab8 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -138,12 +138,113 @@
Headphone Jack, HPLOUT,
Headphone Jack, HPROUT;
};
+
+ panel {
+ compatible = ti,tilcdc,panel;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = lcd_pins_default;
+ pinctrl-1 = lcd_pins_sleep;
+ status = okay;
+ panel-info {
+ ac-bias = 255;
+ ac-bias-intrpt= 0;
+ dma-burst-sz = 16;
+ bpp = 32;
+ fdd = 0x80;
+ sync-edge = 0;
+ sync-ctrl = 1;
+ raster-order = 0;
+ fifo-th = 0;
+ };
+ display-timings {
+ 480x272 {
+ hactive = 480;
+ vactive = 272;
+ hback-porch = 43;
+ hfront-porch= 8;
+ hsync-len = 4;
+ vback-porch = 12;
+ vfront-porch= 4;
+ vsync-len = 10;
+ clock-frequency = 900;
+ hsync-active= 0;
+ vsync-active= 0;
+ };
+ };
+ };
};
am33xx_pinmux {
pinctrl-names = default;
pinctrl-0 = gpio_keys_s0 clkout2_pin;
+ lcd_pins_default: lcd_pins_default {
+ pinctrl-single,pins =
+ 0x20 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad8.lcd_data16
*/
+ 0x24 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad9.lcd_data17
*/
+ 0x28 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad10.lcd_data18
*/
+ 0x2c (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad11.lcd_data19
*/
+ 0x30 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad12.lcd_data20
*/
+ 0x34 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad13.lcd_data21
*/
+ 0x38 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad14.lcd_data22
*/
+ 0x3c (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad15.lcd_data23
*/
+ 0xa0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0
*/
+ 0xa4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1
*/
+ 0xa8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2
*/
+ 0xac (PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3
*/
+ 0xb0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4
*/
+ 0xb4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5
*/
+ 0xb8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6
*/
+ 0xbc (PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7
*/
+ 0xc0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8
*/
+ 0xc4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9
*/
+ 0xc8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data10.lcd_data10 */
+ 0xcc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data11.lcd_data11 */
+ 0xd0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data12.lcd_data12 */
+ 0xd4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data13.lcd_data13 */
+ 0xd8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data14.lcd_data14 */
+ 0xdc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data15.lcd_data15 */
+ 0xe0 (PIN_OUTPUT | MUX_MODE0) /* lcd_vsync.lcd_vsync
*/
+ 0xe4 (PIN_OUTPUT | MUX_MODE0) /* lcd_hsync.lcd_hsync
*/
+ 0xe8 (PIN_OUTPUT | MUX_MODE0) /* lcd_pclk.lcd_pclk */
+
Re: regressions in linux-next?
On 04/22/2014 10:13 AM, Nishanth Menon wrote: Logs with with DEBUG_LL and early printk below: Thread: http://marc.info/?t=139817273800014r=1w=2 On 04/22/2014 08:18 AM, Nishanth Menon wrote: next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat8 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqa known 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX 7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS 8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C 9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6 looks like my fdt_high was 0x and fdt was at 0x80f8 :( so got stomped all over... Time for me to verify every platform again. ok, boards updated with u-boot fixes etc.. next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2o4V7QFmX This one is in discussion in this thread. 2: am3517-evm: Boot PASS: http://slexy.org/raw/s21U08MZIu 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2TYm46GgG 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s21wjoqqjl 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2X8Rh0sSw we know of this one. 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s29BVtv6dR 7: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s21ThDvDWV 8: beaglebone-black: Boot PASS: http://slexy.org/raw/s20XNhvNId 9: beaglebone: Boot PASS: http://slexy.org/raw/s2SqD9D9X8 10: craneboard: Boot PASS: http://slexy.org/raw/s20bcCjsJi 11: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s20K7XSURP 12: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2oDI6XGSV 13: n900: Boot PASS: http://slexy.org/raw/s2F9nMXZJr 14: pandaboard-es: Boot PASS: http://slexy.org/raw/s21M66ujw0 15: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2G7n7kez5 16:sdp2430: Boot PASS: http://slexy.org/raw/s21OIS6Z6H 17:sdp3430: Boot PASS: http://slexy.org/raw/s20pO2iusO 18:sdp4430: Boot PASS: http://slexy.org/raw/s20SVaZoDZ 19: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2H8TeWUxt TOTAL = 19 boards, Booted Boards = 17, No Boot boards = 2 Apologies on the noise. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regressions in linux-next?
On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation. I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward. We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: AM3517: Disable absent IPs inherited from OMAP3
AM3517 inherits OMAP3 dts file, but does not have all the IPs
that are present on OMAP3. This patch disables the following
absent IPs for AM3517: Mailbox, IVA, MMU_ISP, MPU_IVA SmartReflex.
A label had to be added for IVA node in omap3.dtsi to be able to
get a reference to the node for disabling.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am3517.dtsi | 16
arch/arm/boot/dts/omap3.dtsi | 2 +-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index 788391f..5a452fd 100644
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -62,5 +62,21 @@
};
};
+iva {
+ status = disabled;
+};
+
+mailbox {
+ status = disabled;
+};
+
+mmu_isp {
+ status = disabled;
+};
+
+smartreflex_mpu_iva {
+ status = disabled;
+};
+
/include/ am35xx-clocks.dtsi
/include/ omap36xx-am35xx-omap3430es2plus-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 5e5790f..f45f77f 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -61,7 +61,7 @@
ti,hwmods = mpu;
};
- iva {
+ iva: iva {
compatible = ti,iva2.2;
ti,hwmods = iva;
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: dts: OMAP5: Add mailbox dt node to fix boot warning
Add the mailbox device DT node for OMAP5 SoC. The OMAP5 mailbox
IP is identical to that used in OMAP4.
The OMAP5 hwmod data no longer publishes the module address space,
so this patch fixes the WARN_ON backtrace associated with the
following trace during the kernel boot:
omap_hwmod: mailbox: doesn't have mpu register target base.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6f3de22..e8988bb 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -630,6 +630,13 @@
status = disabled;
};
+ mailbox: mailbox@4a0f4000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4a0f4000 0x200;
+ interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mailbox;
+ };
+
timer1: timer@4ae18000 {
compatible = ti,omap5430-timer;
reg = 0x4ae18000 0x80;
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Minor OMAP DTS fixes
Hi Tony, Benoit, This series includes couple of minor fixes in the OMAP DTS files. The patches are based on 3.15-rc2. The first patch fixes the only WARN_ON trace present during kernel boot on OMAP5 uEVM, and this has been present since some time now. [0.045578] [ cut here ] [0.045598] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc() [0.045605] omap_hwmod: mailbox: doesn't have mpu register target base [0.045611] Modules linked in: [0.045625] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-1-gb5e85a0 #45 [0.045653] [c0015724] (unwind_backtrace) from [c00120f4] (show_stack+0x10/0x14) [0.045672] [c00120f4] (show_stack) from [c05a1ccc] (dump_stack+0x78/0x94) [0.045686] [c05a1ccc] (dump_stack) from [c0042a74] (warn_slowpath_common+0x6c/0x8c) [0.045698] [c0042a74] (warn_slowpath_common) from [c0042b28] (warn_slowpath_fmt+0x30/0x40) [0.045710] [c0042b28] (warn_slowpath_fmt) from [c0803b40] (_init+0x1c0/0x3dc) [0.045724] [c0803b40] (_init) from [c0029c8c] (omap_hwmod_for_each+0x34/0x5c) [0.045736] [c0029c8c] (omap_hwmod_for_each) from [c08042b0] (__omap_hwmod_setup_all+0x24/0x40) [0.045748] [c08042b0] (__omap_hwmod_setup_all) from [c00088b8] (do_one_initcall+0x34/0x160) [0.045761] [c00088b8] (do_one_initcall) from [c07f7bf4] (kernel_init_freeable+0xfc/0x1c8) [0.045772] [c07f7bf4] (kernel_init_freeable) from [c059c4f4] (kernel_init+0x8/0xe4) [0.045784] [c059c4f4] (kernel_init) from [c000eaa8] (ret_from_fork+0x14/0x2c) [0.045826] ---[ end trace c25fc521f2569d3c ]--- The last patch eliminates the following traces on AM3517 based boards. [0.418496] platform iva.2: Cannot lookup hwmod 'iva' [0.454352] platform 48094000.mailbox: Cannot lookup hwmod 'mailbox' [0.460610] platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp' [0.464065] platform 480c9000.smartreflex: Cannot lookup hwmod 'smartreflex_mpu_iva' There are a few other such traces remaining, but these are all on valid nodes. [0.420275] platform 480c5000.aes: Cannot lookup hwmod 'aes' [0.462403] platform 480c3000.sham: Cannot lookup hwmod 'sham' [0.463246] platform 480cb000.smartreflex: Cannot lookup hwmod 'smartreflex_core' [0.477243] platform 480ab000.usb_otg_hs: Cannot lookup hwmod 'usb_otg_hs' regards Suman Suman Anna (3): ARM: dts: OMAP5: Add mailbox dt node to fix boot warning ARM: dts: OMAP2: Fix interrupts for OMAP2420 mailbox ARM: dts: AM3517: Disable absent IPs inherited from OMAP3 arch/arm/boot/dts/am3517.dtsi | 16 arch/arm/boot/dts/omap2.dtsi| 7 --- arch/arm/boot/dts/omap2420.dtsi | 8 arch/arm/boot/dts/omap2430.dtsi | 7 +++ arch/arm/boot/dts/omap3.dtsi| 2 +- arch/arm/boot/dts/omap5.dtsi| 7 +++ 6 files changed, 39 insertions(+), 8 deletions(-) -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: dts: OMAP2: Fix interrupts for OMAP2420 mailbox
The mailbox module is capable of generating two interrupts
to MPU in OMAP2420, compared to one in OMAP2430. The second
interrupt is to handle interrupts from the additional IVA
processor present only on OMAP2420.
Move the current common mailbox DT node into the SoC
specific files to allow the above differentiation. Also,
added back the interrupt-names on OMAP2420, that were
previously defined in hwmod data.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap2.dtsi| 7 ---
arch/arm/boot/dts/omap2420.dtsi | 8
arch/arm/boot/dts/omap2430.dtsi | 7 +++
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 22f35ea..8f8c07d 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -71,13 +71,6 @@
interrupts = 58;
};
- mailbox: mailbox@48094000 {
- compatible = ti,omap2-mailbox;
- ti,hwmods = mailbox;
- reg = 0x48094000 0x200;
- interrupts = 26;
- };
-
intc: interrupt-controller@1 {
compatible = ti,omap2-intc;
interrupt-controller;
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 85b1fb0..2d99798 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -125,6 +125,14 @@
dma-names = tx, rx;
};
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap2-mailbox;
+ reg = 0x48094000 0x200;
+ interrupts = 26, 34;
+ interrupt-names = dsp, iva;
+ ti,hwmods = mailbox;
+ };
+
timer1: timer@48028000 {
compatible = ti,omap2420-timer;
reg = 0x48028000 0x400;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index d09697d..42d2c61 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -216,6 +216,13 @@
dma-names = tx, rx;
};
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap2-mailbox;
+ reg = 0x48094000 0x200;
+ interrupts = 26;
+ ti,hwmods = mailbox;
+ };
+
timer1: timer@49018000 {
compatible = ti,omap2420-timer;
reg = 0x49018000 0x400;
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regressions in linux-next?
Hello Ezequiel, On Tue, Apr 22, 2014 at 9:37 PM, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: On Apr 22, Javier Martinez Canillas wrote: On Tue, Apr 22, 2014 at 3:29 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On 04/22/2014 04:18 PM, Nishanth Menon wrote: next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat8 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqa known 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX 7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS 8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C 9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6 12: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2N3afw0TI 13: n900: Boot PASS: http://slexy.org/raw/s21qmT6XCJ 14: pandaboard-es: Boot FAIL: http://slexy.org/raw/s28vlMGdeh 15: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20yHoGHdW 16:sdp2430: Boot PASS: http://slexy.org/raw/s20i8Ir3yn 17:sdp3430: Boot PASS: http://slexy.org/raw/s20t4VTeEB 18:sdp4430: Boot FAIL: http://slexy.org/raw/s21SHcOP01 19: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2qmlRZped TOTAL = 19 boards, Booted Boards = 9, No Boot boards = 10 next-20140417-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Yvz8RRkn 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2JFbaPPVA farm issues. - But peter reports fail as well. Yes, 20140417 boot fails for me on am335x-evmsk. What I can see with early printk is that the boot hangs around/after omap-gpio in all cases without any further information. I have checked the diff between 20140407, which was fine on evmsk regarding to omap-gpio and if I revert: d04b76626e94 gpio: omap: convert driver to use gpiolib irqchip am335x-evmsk boots up fine. With that commit in place PandaBoardES boots fine, but evmsk does not. I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. I've tested 20140422 -next on a Beaglebone black board with a custom gpio-keys cape and it seems to be working fine. Thanks a lot for testing the patches, then is not a problem with all am335x since BBB is booting correctly. All the gpio are registered, but there are some suspicious messages: # dmesg | grep gpio gpiochip_add: registered GPIOs 0 to 31 on device: gpio gpiochip_add: registered GPIOs 32 to 63 on device: gpio gpiochip_add: registered GPIOs 64 to 95 on device: gpio gpiochip_add: registered GPIOs 96 to 127 on device: gpio of_get_named_gpiod_flags: can't parse gpios property of node '/fixedregulator@0[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@44e09000[0]' of_get_named_gpiod_flags exited with status 0 of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@4806[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@481d8000[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@481d8000[0]' Yes those messages are suspicious indeed but I don't think that are related with this patch-set since I've a similar log on my IGEPv2 when booting 3.15-rc2 (which does not include the gpiolib irqchip conversion): dmesg | grep -i gpio [0.505554] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [0.506927] OMAP GPIO hardware version 2.5 [0.508697] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [0.511352] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [0.514007] gpiochip_add: registered GPIOs 96 to 127 on device: gpio [0.516571] gpiochip_add: registered GPIOs 128 to 159 on device: gpio [0.519256] gpiochip_add: registered GPIOs 160 to 191 on device: gpio [0.653167] of_get_named_gpiod_flags: can't parse gpios property of node '/regulator-vdd33[0]' [0.654907] of_get_named_gpiod_flags: can't parse gpios property of node '/regulator-vddvario[0]' [0.656066] of_get_named_gpiod_flags: can't parse gpios property of node '/regulator-vdd33a[0]' [0.657257] of_get_named_gpiod_flags exited with status -517 [0.665985] of_get_named_gpiod_flags exited with status 0 [1.213073] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@4806a000[0]' [1.218109] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@4806c000[0
Re: regressions in linux-next?
Hello Nishanth, On Tue, Apr 22, 2014 at 11:57 PM, Nishanth Menon n...@ti.com wrote: On 04/22/2014 10:13 AM, Nishanth Menon wrote: Logs with with DEBUG_LL and early printk below: Thread: http://marc.info/?t=139817273800014r=1w=2 On 04/22/2014 08:18 AM, Nishanth Menon wrote: next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat8 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqa known 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX 7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS 8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C 9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6 looks like my fdt_high was 0x and fdt was at 0x80f8 :( so got stomped all over... Time for me to verify every platform again. ok, boards updated with u-boot fixes etc.. next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2o4V7QFmX This one is in discussion in this thread. 2: am3517-evm: Boot PASS: http://slexy.org/raw/s21U08MZIu 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2TYm46GgG 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s21wjoqqjl 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2X8Rh0sSw we know of this one. The fix for this is [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5 [0] right? So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you. Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident. 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s29BVtv6dR 7: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s21ThDvDWV 8: beaglebone-black: Boot PASS: http://slexy.org/raw/s20XNhvNId 9: beaglebone: Boot PASS: http://slexy.org/raw/s2SqD9D9X8 10: craneboard: Boot PASS: http://slexy.org/raw/s20bcCjsJi 11: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s20K7XSURP 12: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2oDI6XGSV 13: n900: Boot PASS: http://slexy.org/raw/s2F9nMXZJr 14: pandaboard-es: Boot PASS: http://slexy.org/raw/s21M66ujw0 15: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2G7n7kez5 16:sdp2430: Boot PASS: http://slexy.org/raw/s21OIS6Z6H 17:sdp3430: Boot PASS: http://slexy.org/raw/s20pO2iusO 18:sdp4430: Boot PASS: http://slexy.org/raw/s20SVaZoDZ 19: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2H8TeWUxt TOTAL = 19 boards, Booted Boards = 17, No Boot boards = 2 Apologies on the noise. -- Regards, Nishanth Menon -- Thanks a lot and best regards, Javier [0]: http://www.spinics.net/lists/linux-omap/msg104702.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: regressions in linux-next?
On 04/22/2014 05:45 PM, Javier Martinez Canillas wrote: [...] Time for me to verify every platform again. ok, boards updated with u-boot fixes etc.. next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2o4V7QFmX This one is in discussion in this thread. We just managed to get am335x-evm up and running as well. am335x-evm: Boot PASS: http://slexy.org/raw/s2WSAKSG2S I checked with DEBUG_LL a few mins back on AM335x-sk: http://slexy.org/raw/s2P8L4FGBY 2: am3517-evm: Boot PASS: http://slexy.org/raw/s21U08MZIu 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2TYm46GgG 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s21wjoqqjl 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2X8Rh0sSw we know of this one. The fix for this is [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5 [0] right? Yep, This is a different issue compared to the AM335x-sk discussion. http://marc.info/?l=linux-omapm=139819642824190w=2 two patches for this one: https://patchwork.kernel.org/patch/3871201/ https://patchwork.kernel.org/patch/4034201/ we are still debating about how to go about it. on AM335x-sk: So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you. Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident. I could not find anything interesting yet. Peter did mention that reverting d04b76626e94 helped make the platform boot fine. I am trying to add a few prints and see which specific line does things go bad.. and if so why.. unfortunately, I am using the board remotely as well.. Will try to track this down in the next few hours and post back. [0]: http://www.spinics.net/lists/linux-omap/msg104702.html -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regressions in linux-next?
Hello Linus, On Wed, Apr 23, 2014 at 12:00 AM, Linus Walleij linus.wall...@linaro.org wrote: On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation. The board that is failing to boot with this patch-set is not an OMAP1 based board but the Sitara AM335x Starter Kit (arch/arm/boot/dts/am335x-evmsk.dts). Now, other boards using the same SoC like the Beagle Bone Black are booting correctly and also am335x-evm which is very similar to am335x-evmsk.dts. Nishanth has access to this board and his helping now with the debugging. I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward. Yeah, I'm doing my best to keep this driver up-to-date with the latest changes in gpiolib but it seems that is very hard to change the OMAP GPIO driver without breaking one of the gazillion TI platforms out there... We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ Yours, Linus Walleij Thanks a lot and best regards, Javier -- 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: regressions in linux-next?
On Wed, Apr 23, 2014 at 12:52 AM, Nishanth Menon n...@ti.com wrote: On 04/22/2014 05:45 PM, Javier Martinez Canillas wrote: [...] Time for me to verify every platform again. ok, boards updated with u-boot fixes etc.. next-20140422-omap2plus_defconfig 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2o4V7QFmX This one is in discussion in this thread. We just managed to get am335x-evm up and running as well. am335x-evm: Boot PASS: http://slexy.org/raw/s2WSAKSG2S I checked with DEBUG_LL a few mins back on AM335x-sk: http://slexy.org/raw/s2P8L4FGBY 2: am3517-evm: Boot PASS: http://slexy.org/raw/s21U08MZIu 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2TYm46GgG 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s21wjoqqjl 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2X8Rh0sSw we know of this one. The fix for this is [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5 [0] right? Yep, This is a different issue compared to the AM335x-sk discussion. http://marc.info/?l=linux-omapm=139819642824190w=2 two patches for this one: https://patchwork.kernel.org/patch/3871201/ https://patchwork.kernel.org/patch/4034201/ we are still debating about how to go about it. on AM335x-sk: So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you. Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident. I could not find anything interesting yet. Peter did mention that reverting d04b76626e94 helped make the platform boot fine. I am trying to add a few prints and see which specific line does things go bad.. and if so why.. unfortunately, I am using the board remotely as well.. Will try to track this down in the next few hours and post back. Great, thanks a lot for your help and sorry for the inconvenience! [0]: http://www.spinics.net/lists/linux-omap/msg104702.html -- Regards, Nishanth Menon Best regards, Javier -- 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: regressions in linux-next?
* Javier Martinez Canillas jav...@dowhile0.org [140422 16:03]: Hello Linus, On Wed, Apr 23, 2014 at 12:00 AM, Linus Walleij linus.wall...@linaro.org wrote: On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation. The board that is failing to boot with this patch-set is not an OMAP1 based board but the Sitara AM335x Starter Kit (arch/arm/boot/dts/am335x-evmsk.dts). This does not happen to have anything to do with the ti,no-reset-on-init hack for gpio0 on the am335x-evmsk.dts that's needed to keep DDR powered? See the am43x thread for more info. Now, other boards using the same SoC like the Beagle Bone Black are booting correctly and also am335x-evm which is very similar to am335x-evmsk.dts. Except for the gpio0 hack.. Nishanth has access to this board and his helping now with the debugging. I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward. Yeah, I'm doing my best to keep this driver up-to-date with the latest changes in gpiolib but it seems that is very hard to change the OMAP GPIO driver without breaking one of the gazillion TI platforms out there... We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ I got it to the point where some relatively recent u-boot was loading fine over JTAG but the first stage did not boot properly from NOR for some reason. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix few omap gpmc regressions when booted with device tree
* Tony Lindgren t...@atomide.com [140422 08:24]:
* Javier Martinez Canillas jav...@dowhile0.org [140421 23:55]:
On Tue, Apr 22, 2014 at 2:54 AM, Tony Lindgren t...@atomide.com wrote:
2. There seems to be some timing issues with smc911x where
rsync of larger files and apt-get dist-upgrade can produce
strange errors. This seems to work reliably when booted in
legacy mode.
In what board are you having this issue? The smsc911x driver supports
both SMSC's LAN911x and LAN921x families and I see that we have two
.dtsi files with different timings
(arm/boot/dts/omap-gpmc-smsc{911x,9221}.dtsi).
This is only a wild guess, but maybe your board has a smsc LAN921x
chip but is including omap-gpmc-smsc911x.dtsi on its DTS?
Yes it seems to have two LAN9220s, so this could be the reason.
I don't think we had the omap-gpmc-smsc9221.dtsi when I added the
timings initially.
This is on a sbc-t3730 that I'm using as a gateway that was behaving
reliably before I upgraded it to DT based booting. It's currently
at v3.13-rc3 something, but I don't think we've much GPMC changes
since then.
I'll try upgrading the kernel today and running some tests with
rsync. Looks like we can also remove quite a bit of duplicate
timing data by using omap-gpmc-smsc9221.dtsi, I'll try something
like the patch below.
In any case, I suggest others run some tests on their GPMC Ethernet
too.
+#include omap-gpmc-smsc9221.dtsi
+
The 9221 timings won't work at all on 9220, it requires a 9221.
I'll post a better clean-up patch to use the 911x timings.
Upgraded the kernel and the occasional corruption is still
there. I guess I need to test also the same kernel in legacy
mode to try to narrow it down.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/11] tty: serial: add missing braces
On Tue, Apr 22, 2014 at 09:22:56AM -0500, Felipe Balbi wrote: Hi, On Thu, Mar 20, 2014 at 02:29:57PM -0500, Felipe Balbi wrote: per CodingStyle we should have those braces, no functional changes. Signed-off-by: Felipe Balbi ba...@ti.com Greg, do you want me to refresh and resend this series ? If there are conflicts with my current tree, sure, I'd love to have that. I should be trying to dig out from my patch backlog for 3.16-rc1 by the end of this week... thanks, greg k-h -- 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 8/8] ARM: OMAP2+: timer: Add legacy code for old way of getting fclk
Separate out legacy code for getting timer-fclk and reuse it for
the DT-case as a fallback. All DT users should ideally be specifying
a clock property with a phandle of its clock node. Till the migration
is complete, add a legacy function to keep things working.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/timer.c | 32
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b3db1da..81a29b1 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -248,6 +248,19 @@ static u32 __init omap_dm_timer_get_errata(void)
return OMAP_TIMER_ERRATA_I103_I767;
}
+static int legacy_hwmod_clkget(struct omap_dm_timer *timer, const char
*oh_name)
+{
+ struct omap_hwmod *oh;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh)
+ return -ENODEV;
+
+ timer-fclk = clk_get(NULL, omap_hwmod_get_main_clk(oh));
+ if (IS_ERR(timer-fclk))
+ return PTR_ERR(timer-fclk);
+}
+
static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
const char *fck_source,
const char *property,
@@ -289,6 +302,14 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
* fall back code is to be deleted and we're to return
* PTR_ERR(timer-fclk) here.
*/
+ of_property_read_string_index(np, ti,hwmods, 0,
+ oh_name);
+ if (!oh_name)
+ return -ENODEV;
+
+ r = legacy_hwmod_clkget(timer, oh_name);
+ if (r)
+ return r;
}
} else {
if (omap_dm_timer_reserve_systimer(timer-id))
@@ -320,15 +341,10 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
omap_hwmod_setup_one(oh_name);
omap_hwmod_enable(oh);
- }
- if (!timer-fclk || IS_ERR(timer-fclk)) {
- oh = omap_hwmod_lookup(oh_name);
- if (!oh)
- return -ENODEV;
- timer-fclk = clk_get(NULL, omap_hwmod_get_main_clk(oh));
- if (IS_ERR(timer-fclk))
- return PTR_ERR(timer-fclk);
+ r = legacy_hwmod_clkget(timer, oh_name);
+ if (r)
+ return r;
}
/*
--
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
[PATCH 1/8] ARM: OMAP2+: timer: Add a powerup function
In an effort to isolate the time power initialization for future purposes, add
a function to do the same. This primarily involves a hwmod lookup, setup and
enable.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/timer.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index dfb19df..ec427e6 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -210,6 +210,31 @@ static void __init omap_dmtimer_init(void)
}
}
+int __init omap_dmtimer_powerup(struct device_node *np)
+{
+ struct omap_hwmod *oh;
+ const char *oh_name = NULL;
+ int ret;
+
+ of_property_read_string_index(np, ti,hwmods, 0, oh_name);
+ if (!oh_name)
+ return -ENODEV;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh)
+ return -ENODEV;
+
+ ret = omap_hwmod_setup_one(oh_name);
+ if (ret)
+ return ret;
+
+ ret = omap_hwmod_enable(oh);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
/**
* omap_dm_timer_get_errata - get errata flags for a timer
*
--
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
[PATCH 5/8] ARM: OMAP2+: timer: Use of_clk_get for DT platforms
For DT-booting platforms, use of_clk_get to get the fclk for system timers. Separate out the legacy code for non-DT platform use. Signed-off-by: Joel Fernandes jo...@ti.com --- arch/arm/mach-omap2/timer.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index ea91ef9..4fcfd7a 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -277,6 +277,10 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer, if (!timer-io_base) return -ENXIO; + timer-fclk = of_clk_get(np, 0); + if (IS_ERR(timer-fclk)) + return PTR_ERR(timer-fclk); + r = omap_dmtimer_powerup(np); if (r) return r; @@ -308,14 +312,13 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer, if (!timer-io_base) return -ENXIO; + timer-fclk = clk_get(NULL, omap_hwmod_get_main_clk(oh)); + if (IS_ERR(timer-fclk)) + return PTR_ERR(timer-fclk); omap_hwmod_setup_one(oh_name); omap_hwmod_enable(oh); } - /* After the dmtimer is using hwmod these clocks won't be needed */ - timer-fclk = clk_get(NULL, omap_hwmod_get_main_clk(oh)); - if (IS_ERR(timer-fclk)) - return PTR_ERR(timer-fclk); /* * Clock reparenting code, goes away for DT-boot atleast, -- 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
[PATCH 0/8] OMAP2+ system timer cleanup series
Here is a clean up series that attempts to separate out some of the DT-only vs legacy system timer usage for OMAP2+. Emphasis is on separating legacy stuff, and abstracting annoyances such as hwmod to give us the flexibilty for the migration. The series will relieve some of the difficulties in moving out the timer code from mach layer. As such it is incremental and there is a bit of duplication for fallback cases, but emphasis is on keeping things working during the migration. Earlier series posted for dmtimer cleanup, and changes for OMAP1 is at [1]. [1] https://lkml.org/lkml/2014/4/16/737 Joel Fernandes (8): ARM: OMAP2+: timer: Add a powerup function ARM: OMAP2+: timer: Simplify clock event/source name setting ARM: OMAP2+: timer: Add comment on timer clk parenting ARM: OMAP2+: timer: Remove hwmod look-up dependency for DT-boot ARM: OMAP2+: timer: Use of_clk_get for DT platforms ARM: OMAP2+: timer: Fix error message to not use hwmod structure ARM: OMAP2+: timer: Add fallback for of_clk_get ARM: OMAP2+: timer: Add legacy code for old way of getting fclk arch/arm/mach-omap2/timer.c | 111 +-- 1 file changed, 85 insertions(+), 26 deletions(-) -- 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
[PATCH 3/8] ARM: OMAP2+: timer: Add comment on timer clk parenting
Add a comment describing the state of system timer clock parenting. The code following the comment should be deleted once all platforms can do DT boot, and specially should not be executed for DT platforms once we can specify default clock parents through DT. Signed-off-by: Joel Fernandes jo...@ti.com --- arch/arm/mach-omap2/timer.c |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index f192a41..9fdff5b 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -313,6 +313,10 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer, if (IS_ERR(timer-fclk)) return PTR_ERR(timer-fclk); + /* +* Clock reparenting code, goes away for DT-boot atleast, +* once clock layer can do it through DT. +*/ src = clk_get(NULL, fck_source); if (IS_ERR(src)) return PTR_ERR(src); -- 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: regressions in linux-next?
On 01:08-20140423, Javier Martinez Canillas wrote: [...] on AM335x-sk: So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you. Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident. I could not find anything interesting yet. Peter did mention that reverting d04b76626e94 helped make the platform boot fine. I am trying to add a few prints and see which specific line does things go bad.. and if so why.. unfortunately, I am using the board remotely as well.. Will try to track this down in the next few hours and post back. Great, thanks a lot for your help and sorry for the inconvenience! Yep - If I am correct, and as we all suspected, GPIO0_7 which controls the VTT regulator for DDR is getting configured as input, instead of output. http://slexy.org/raw/s2gReMRZI6 (with diff: http://slexy.org/view/s20nueCE8H - ignore many of the prints as I was trying to truncate and isolate - had to switch to non-relaxed versions of writes to force sequencing with barriers to trace it down..) Anyways, the key log is [0]: gpiochip_irq_map - calls irq_set_irq_type(irq, chip-irq_default_type); which inturn triggers: gpio-omap.c's gpio_irq_type in this, logic: if (!LINE_USED(bank-mod_usage, offset)) is invoked prior to setting the input type for the GPIO 0_7 (you can see the logic walks through setting every GPIO to input!). The original usage as far as I could discern was that this function was only called after probe got completed as the gpio requests were triggered. There are probably many hacks possible, but a cleaner solution might involve gpio_irqchip knowing when to set the type and knowing which gpios not to mess with. Example hack: Since we call gpiochip_irqchip_add with IRQ_TYPE_NONE, in gpio-omap's gpio_irq_type could do: if (type == IRQ_TYPE_NONE) return 0; boots, http://slexy.org/raw/s24M8lHqZX - but ofcourse, there'd be other side effects I have'nt thought through.. [0]: [ 25.504976] DONE gpio_irq_type: 533 bank 0xf9e07000, offset 7 [ 25.511052] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-next-20140422-3-gd9fc91f-dirty #12 [ 25.520811] [c0014cf0] (unwind_backtrace) from [c0011984] (show_stack+0x10/0x14) [ 25.528870] [c0011984] (show_stack) from [c05421b8] (dump_stack+0x78/0x94) [ 25.536390] [c05421b8] (dump_stack) from [c03016c8] (gpio_irq_type+0x1b4/0x218) [ 25.544359] [c03016c8] (gpio_irq_type) from [c008f0d4] (__irq_set_trigger+0x5c/0xfc) [ 25.552774] [c008f0d4] (__irq_set_trigger) from [c0090888] (irq_set_irq_type+0x38/0x58) [ 25.561455] [c0090888] (irq_set_irq_type) from [c02fbf4c] (gpiochip_irq_map+0x60/0x68) [ 25.570047] [c02fbf4c] (gpiochip_irq_map) from [c0092908] (irq_domain_associate+0x70/0x1b8) [ 25.579087] [c0092908] (irq_domain_associate) from [c0092abc] (irq_create_mapping+0x6c/0xfc) [ 25.588216] [c0092abc] (irq_create_mapping) from [c02fbe4c] (gpiochip_irqchip_add+0xa8/0xf0) [ 25.597346] [c02fbe4c] (gpiochip_irqchip_add) from [c0300bb8] (omap_gpio_probe+0x2bc/0x8a4) [ 25.606386] [c0300bb8] (omap_gpio_probe) from [c0354ee4] (platform_drv_probe+0x18/0x48) [ 25.615068] [c0354ee4] (platform_drv_probe) from [c03535d0] (driver_probe_device+0x110/0x224) [ 25.624286] [c03535d0] (driver_probe_device) from [c0351e64] (bus_for_each_drv+0x5c/0x88) [ 25.633146] [c0351e64] (bus_for_each_drv) from [c035348c] (device_attach+0x74/0x8c) [ 25.641471] [c035348c] (device_attach) from [c0352b68] (bus_probe_device+0x88/0xb0) [ 25.649793] [c0352b68] (bus_probe_device) from [c035114c] (device_add+0x3a8/0x4dc) [ 25.658029] [c035114c] (device_add) from [c045ccb8] (of_platform_device_create_pdata+0x70/0x94) [ 25.667428] [c045ccb8] (of_platform_device_create_pdata) from [c045cdb8] (of_platform_bus_create+0xdc/0x184) [ 25.677990] [c045cdb8] (of_platform_bus_create) from [c045ce1c] (of_platform_bus_create+0x140/0x184) [ 25.687835] [c045ce1c] (of_platform_bus_create) from [c045cec0] (of_platform_populate+0x60/0x98) [ 25.697323] [c045cec0] (of_platform_populate) from [c07ad190] (pdata_quirks_init+0x34/0x44) [ 25.706364] [c07ad190] (pdata_quirks_init) from [c07ace64] (omap_generic_init+0x10/0x1c) [ 25.715136] [c07ace64] (omap_generic_init) from [c079e50c] (customize_machine+0x1c/0x40) [ 25.723906] [c079e50c] (customize_machine) from [c0008a64] (do_one_initcall+0x80/0x1c8) [ 25.732591] [c0008a64] (do_one_initcall) from [c079bc94] (kernel_init_freeable+0xfc/0x1cc) [ 25.741544] [c079bc94] (kernel_init_freeable) from [c053cb1c] (kernel_init+0x8/0xe4) [ 25.749958] [c053cb1c] (kernel_init) from [c000e708] (ret_from_fork+0x14/0x2c) -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org
[PATCH 7/8] ARM: OMAP2+: timer: Add fallback for of_clk_get
Not all platforms currently will support of_clk_get on timer
because they may not have clock property in their DT nodes. Add
code to handle this case so that things are kept working. Finally
we can delete this code once all system timer nodes have a clock
property.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/timer.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 519ccfd..b3db1da 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -277,13 +277,19 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (!timer-io_base)
return -ENXIO;
- timer-fclk = of_clk_get(np, 0);
- if (IS_ERR(timer-fclk))
- return PTR_ERR(timer-fclk);
-
r = omap_dmtimer_powerup(np);
if (r)
return r;
+
+ timer-fclk = of_clk_get(np, 0);
+ if (IS_ERR(timer-fclk)) {
+ /*
+* Support DT platforms temporarily that don't have
+* clock property in their dts yet. Ultimately this
+* fall back code is to be deleted and we're to return
+* PTR_ERR(timer-fclk) here.
+*/
+ }
} else {
if (omap_dm_timer_reserve_systimer(timer-id))
return -ENODEV;
@@ -312,14 +318,19 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (!timer-io_base)
return -ENXIO;
- timer-fclk = clk_get(NULL, omap_hwmod_get_main_clk(oh));
- if (IS_ERR(timer-fclk))
- return PTR_ERR(timer-fclk);
-
omap_hwmod_setup_one(oh_name);
omap_hwmod_enable(oh);
}
+ if (!timer-fclk || IS_ERR(timer-fclk)) {
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh)
+ return -ENODEV;
+ timer-fclk = clk_get(NULL, omap_hwmod_get_main_clk(oh));
+ if (IS_ERR(timer-fclk))
+ return PTR_ERR(timer-fclk);
+ }
+
/*
* Clock reparenting code, goes away for DT-boot atleast,
* once clock layer can do it through DT.
--
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
[PATCH 4/8] ARM: OMAP2+: timer: Remove hwmod look-up dependency for DT-boot
hwmod look ups should no longer directly happen for dmtimer users of
DT-boot platforms. We separate out the code for platforms that are
still non-DT. Ultimately this code should be deleted if all platforms
are converted to DT-boot.
We use omap_dmtimer_powerup introduced earlier in the series to abstract
out the hwmod dependency for the same. This will help us move the generic
DT specific code out into drivers/clocksource/ later.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/timer.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 9fdff5b..ea91ef9 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -266,10 +266,6 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (!np)
return -ENODEV;
- of_property_read_string_index(np, ti,hwmods, 0, oh_name);
- if (!oh_name)
- return -ENODEV;
-
timer-irq = irq_of_parse_and_map(np, 0);
if (!timer-irq)
return -ENXIO;
@@ -277,19 +273,24 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
timer-io_base = of_iomap(np, 0);
of_node_put(np);
+
+ if (!timer-io_base)
+ return -ENXIO;
+
+ r = omap_dmtimer_powerup(np);
+ if (r)
+ return r;
} else {
if (omap_dm_timer_reserve_systimer(timer-id))
return -ENODEV;
sprintf(name, timer%d, timer-id);
oh_name = name;
- }
- oh = omap_hwmod_lookup(oh_name);
- if (!oh)
- return -ENODEV;
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh)
+ return -ENODEV;
- if (!of_have_populated_dt()) {
r = omap_hwmod_get_resource_byname(oh, IORESOURCE_IRQ, NULL,
irq);
if (r)
@@ -303,11 +304,14 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
/* Static mapping, never released */
timer-io_base = ioremap(mem.start, mem.end - mem.start);
+
+ if (!timer-io_base)
+ return -ENXIO;
+
+
+ omap_hwmod_setup_one(oh_name);
+ omap_hwmod_enable(oh);
}
-
- if (!timer-io_base)
- return -ENXIO;
-
/* After the dmtimer is using hwmod these clocks won't be needed */
timer-fclk = clk_get(NULL, omap_hwmod_get_main_clk(oh));
if (IS_ERR(timer-fclk))
@@ -333,10 +337,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
clk_put(src);
- omap_hwmod_setup_one(oh_name);
- omap_hwmod_enable(oh);
__omap_dm_timer_init_regs(timer);
-
if (posted)
__omap_dm_timer_enable_posted(timer);
--
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
[PATCH 2/8] ARM: OMAP2+: timer: Simplify clock event/source name setting
For the OMAPs, we're setting up only one clockevent and clocksource. Further,
for DT boot there's no easy way to get the timer name and currently this is
done in an ugly way by reading a hwmod entry. So let's just set it to a simpler
name like timer_clkev and timer_clksrc.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/timer.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ec427e6..f192a41 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -251,7 +251,6 @@ static u32 __init omap_dm_timer_get_errata(void)
static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
const char *fck_source,
const char *property,
-const char **timer_name,
int posted)
{
char name[10]; /* 10 = sizeof(gptXX_Xck0) */
@@ -290,8 +289,6 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (!oh)
return -ENODEV;
- *timer_name = oh-name;
-
if (!of_have_populated_dt()) {
r = omap_hwmod_get_resource_byname(oh, IORESOURCE_IRQ, NULL,
irq);
@@ -365,8 +362,10 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
*/
__omap_dm_timer_override_errata(clkev, OMAP_TIMER_ERRATA_I103_I767);
+ clockevent_gpt.name = timer_clkev;
+
res = omap_dm_timer_init_one(clkev, fck_source, property,
-clockevent_gpt.name, OMAP_TIMER_POSTED);
+OMAP_TIMER_POSTED);
BUG_ON(res);
omap2_gp_timer_irq.dev_id = clkev;
@@ -489,10 +488,11 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
clksrc.errata = omap_dm_timer_get_errata();
res = omap_dm_timer_init_one(clksrc, fck_source, property,
-clocksource_gpt.name,
OMAP_TIMER_NONPOSTED);
BUG_ON(res);
+ clocksource_gpt.name = timer_clksrc;
+
__omap_dm_timer_load_start(clksrc,
OMAP_TIMER_CTRL_AR, 0,
OMAP_TIMER_NONPOSTED);
--
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
[PATCH 6/8] ARM: OMAP2+: timer: Fix error message to not use hwmod structure
oh-name is no longer used, correct the error message.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/mach-omap2/timer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 4fcfd7a..519ccfd 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -331,8 +331,8 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (clk_get_parent(timer-fclk) != src) {
r = clk_set_parent(timer-fclk, src);
if (r 0) {
- pr_warn(%s: %s cannot set source\n, __func__,
- oh-name);
+ pr_warn(%s: cannot set timer's source\n, __func__);
+ WARN_ON(1);
clk_put(src);
return r;
}
--
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
