RE: [PATCH] ARM: OMAP5: select SCU
Sorry for top posting. Can you just add static inlines functions in header file and #ifdef it for OMAP5. Regards, Santosh From: Stehle, Vincent Sent: Thursday, May 16, 2013 7:59 PM To: Shilimkar, Santosh Cc: Vincent Stehlé; Tony Lindgren; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] ARM: OMAP5: select SCU So the exact commit breaking OMAP5 link for me is: 883a106 ARM: default machine descriptor for multiplatform The breakage seems to be a side effect of not selecting ARCH_VEXPRESS any more, which causes HAVE_ARM_SCU to not be selected any more, too, when compiling only for OMAP5. IMHO this only reveals a deeper issue. Probably the ideal fix would be to remove all references to the scu_ functions for OMAP5, but those seem to exist in files and functions, common to OMAP4 and 5 (sleep44xx.S, omap-smp.c). How would you deal with that, please? Best regards, V. -- 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: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
Paul, Tony, On Friday 05 April 2013 10:20 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]: [..] Can't we already trim the am33xx hwmod data after your patches for v3.10 as am33xx is already DT only? Unfortunately we cannot create negative diffstat in other ways for v3.10 merge window as we cannot make omap4 DT only just quite yet. Yes we can and I can take a stab it tomorrow. The only thing is I might need some support for testing but thats manageable. Will take a stab at it tomorrow and if everything goes well, post a patch for smae. Patch for the AM33XX to trim is end of the email. Thanks to Sricharan and Pekon for patch and testing. Looping both Vaibhav's if they have any objection on the patch. Regards, Santosh From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file For whatever reason, we again missed the merge window for the subject series, I would like to know your plan on the subject series for at least 3.11. Asking *well in advance* to avoid late merge related discussions. Thanks to Vaibhav, AM33XX patch is tested and validated with some updates considering upcoming PM support for AM33XX. So that patch will be included in the series. Rajendra will follow up the patchset if there is some re-basing is needed since I will away for few weeks because of travel. OMAP5 data is the *only* thing which is gating the device to boot from mainline. Thanks in advance. Regards, Santosh -- 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
3.9 regression : CAM_XCLKA wrong frequency setting.
Hi, Laurent, you are on the recipient list because the symptom is visible throug your driver. I found the other name looking in the clock related files. Please apologize if you are not concerned by this mail. Symptom : External clock CAM_XCLKA frequency is wrong with 3.9, it was ok until 3.6. Everything else is working fine, except the fps are higher, and the image quality sucks because the input clock is out of spec. Oscilloscope measured freq is around 30 MHz instead of the 24 MHz the sensor is asking for. Hardware : dm3730, with 19.2 MHz crystal, running at OPP100 The register frequency settings seems to be ok, and they are the same as in 3.6.11 : CM_CLKSEL2_PLL : 0x04816807 19, 2 * 360 / 8 = 864 MHz this value is already set when I look at it in u-boot CM_CLKSEL_CAM : 0x5 864 / 5 = 172,8 MHz this value is set through the clock framework by the omap3isp driver code ISP.TCTRL_CTRL : 0x7 172,8 / 7 = 24,685... MHz this value is set by the omap3isp driver code However, as stated before, the actual output frequency is NOT 24 MHz but around 30. If dpll4 frequency is wrong, what other clock would be affected ? What can I do to debug this ? Laurent, I believe you have a camera add-on board for the beagle xm, could you test and report wether you can reproduce this bug ? Attached is the boot log with 3.9, with some debugging messages activated. Thank you for your help, Regards, Jean-Philippe François 3.9dmesg Description: Binary data
[PATCH] i2c: busses: remove superfluous comment
The comment already got copypasted around and is not really useful.
Remove it.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c/busses/i2c-davinci.c|1 -
drivers/i2c/busses/i2c-designware-platdrv.c |1 -
drivers/i2c/busses/i2c-omap.c |1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index cf20e06..2daa253 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -646,7 +646,6 @@ static int davinci_i2c_probe(struct platform_device *pdev)
struct resource *mem, *irq;
int r;
- /* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(pdev-dev, no mem resource?\n);
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 35b70a1..da53d64 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -87,7 +87,6 @@ static int dw_i2c_probe(struct platform_device *pdev)
struct resource *mem;
int irq, r;
- /* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(pdev-dev, no mem resource?\n);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..b241ae6 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1084,7 +1084,6 @@ omap_i2c_probe(struct platform_device *pdev)
u32 rev;
u16 minor, major, scheme;
- /* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(pdev-dev, no mem resource?\n);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V2] ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature
Layout of DEV_FEATURE register (offset = 0x604) is different
between TI81xx and AM33xx device, so create separate function
which will check for features available on specific AM33xx SoC
and set the flags accordingly.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@linaro.org
---
Changes from V1:
- Removed SHIFT value, as it never gets used in code
- Used BIT() macro for MASK definition
arch/arm/mach-omap2/control.h |4
arch/arm/mach-omap2/id.c | 13 +
arch/arm/mach-omap2/io.c |2 +-
arch/arm/mach-omap2/soc.h |1 +
4 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index e6c3281..174eb41 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -358,6 +358,10 @@
#define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH 0x2
#define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3 22)
+/* DEV Feature register to identify AM33XX features */
+#define AM33XX_DEV_FEATURE 0x604
+#define AM33XX_SGX_MASKBIT(29)
+
/* CONTROL OMAP STATUS register to identify OMAP3 features */
#define OMAP3_CONTROL_OMAP_STATUS 0x044c
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 1272c41..44be835 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -302,6 +302,19 @@ void __init ti81xx_check_features(void)
omap3_cpuinfo();
}
+void __init am33xx_check_features(void)
+{
+ u32 status;
+
+ omap_features = OMAP3_HAS_NEON;
+
+ status = omap_ctrl_readl(AM33XX_DEV_FEATURE);
+ if (status AM33XX_SGX_MASK)
+ omap_features |= OMAP3_HAS_SGX;
+
+ omap3_cpuinfo();
+}
+
void __init omap3xxx_check_revision(void)
{
const char *cpu_rev;
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 09abf99..06a8946 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -576,7 +576,7 @@ void __init am33xx_init_early(void)
omap2_set_globals_prm(AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE));
omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
- ti81xx_check_features();
+ am33xx_check_features();
am33xx_voltagedomains_init();
am33xx_powerdomains_init();
am33xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 197cc16..fd4507b 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -424,6 +424,7 @@ void omap4xxx_check_revision(void);
void omap5xxx_check_revision(void);
void omap3xxx_check_features(void);
void ti81xx_check_features(void);
+void am33xx_check_features(void);
void omap4xxx_check_features(void);
/*
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature
-Original Message- From: Kevin Hilman [mailto:khil...@linaro.org] Sent: Tuesday, May 14, 2013 3:23 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; t...@atomide.com; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH] ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature Vaibhav Hiremath hvaib...@ti.com writes: Layout of DEV_FEATURE register (offset = 0x604) is different between TI81xx and AM33xx device, so create separate function which will check for features available on specific AM33xx SoC and set the flags accordingly. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Minor nit below, otherwise... Reviewed-by: Kevin Hilman khil...@linaro.org --- arch/arm/mach-omap2/control.h |5 + arch/arm/mach-omap2/id.c | 13 + arch/arm/mach-omap2/io.c |2 +- arch/arm/mach-omap2/soc.h |1 + 4 files changed, 20 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach- omap2/control.h index e6c3281..4acdfc5 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -358,6 +358,11 @@ #define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH 0x2 #define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3 22) +/* DEV Feature register to identify AM33XX features */ +#define AM33XX_DEV_FEATURE 0x604 +#define AM33XX_SGX_SHIFT 29 You don't need the shift value anywhere in the code, so... +#define AM33XX_SGX_MASK(1 AM33XX_SGX_SHIFT) #define AM33XX_SGX_MASK BIT(29) instead? Otherwise, rest of patch looks fine. Thanks for the review Kevin. I just sent out V2 version of the patch with your reviewed-by With changes you mentioned. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, March 27, 2013 11:15 PM To: Tony Lindgren; Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Nayak, Rajendra Subject: Re: [PATCH-V2] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock On Wed, 27 Mar 2013, Vaibhav Hiremath wrote: It is required to enable respective clock-domain before enabling any clock/module inside that clock-domain. During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so it will be disabled even if childs of this clock-domain is enabled, which keeps child modules in idle mode. This fixes the kernel crash observed on AM335xEVM-SK platform, where clkdiv32_ick clock is being used as a gpio debounce clock and since clkdiv32k_ick is in idle mode it leads to below crash - Crash Log: == [2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa1ac150 [2.606434] Internal error: : 1028 [#1] SMP ARM [2.611207] Modules linked in: [2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4) [2.620973] PC is at _set_gpio_debounce+0x60/0x104 [2.626025] LR is at clk_enable+0x30/0x3c Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Tony, if it isn't too late, could this one be added to your 3.9-rc fixes series? Looks like we missed this so far. Tony, can you merge this patch for v3.10-rc ? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mfd: twl-core: convert to module_i2c_driver()
On 05/17/2013 01:58 AM, Tony Lindgren wrote: * Samuel Ortiz sa...@linux.intel.com [130516 15:22]: Hi Grygorii, On Tue, Apr 23, 2013 at 04:19:10PM +0300, Grygorii Strashko wrote: Shift TWL initialization to module/device init layer, because I2C now is not initialized on subsys init layer and shifted to module/device init layer instead. The I2C -- TWL dependency should be resolved in drivers/Makefile now. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- drivers/mfd/twl-core.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) I applied this one to mfd-next for now, and will move it to mfd-fixes if someone confirms that this is indeed a fix. Thanks, AFAIK it can wait until v3.11 merge window. Regards, Tony Thanks, it's optimization which reduces the number of deferred probes at boot Regards, -grygorii -- 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] ARM: OMAP AM33XX: clock data: Enable clkout2 output on SoC pad
-Original Message- From: Hiremath, Vaibhav Sent: Tuesday, May 07, 2013 3:10 PM To: linux-omap@vger.kernel.org Cc: t...@atomide.com; Cousson, Benoit; p...@pwsan.com; linux-arm- ker...@lists.infradead.org; Hiremath, Vaibhav Subject: [PATCH 0/2] ARM: OMAP AM33XX: clock data: Enable clkout2 output on SoC pad 'clkout2' comes out on the device pad and is being used by various external on-board peripherals like, Audio codecs, Wilink and stuff. So enable the clkout2 by default during init sequence itself along with right pinmux configuration clkout2 output. Also, add the missing entry of clkout2_ck to the AM33xx clock table. As far as enabling of clkout2 during init is concerned, we can argue that it can be handled using DT property and enable the clock only when specified; but not until OMAP clock-tree migration to DT. Vaibhav Hiremath (2): ARM: OMAP AM33XX: clock data: Enable clkout2 as part of init ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output arch/arm/boot/dts/am335x-bone.dts |8 +++- arch/arm/boot/dts/am335x-evm.dts |8 +++- arch/arm/boot/dts/am335x-evmsk.dts|8 +++- arch/arm/mach-omap2/cclock33xx_data.c |2 ++ 4 files changed, 23 insertions(+), 3 deletions(-) Tony, Paul and Benoit, Any update on this series? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: AM33xx: Add missing reset status info to GFX hwmod
-Original Message-
From: Hiremath, Vaibhav
Sent: Sunday, May 05, 2013 12:18 AM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; linux-arm-ker...@lists.infradead.org; Hiremath,
Vaibhav; Paul Walmsley
Subject: [PATCH] ARM: OMAP2+: AM33xx: Add missing reset status info to
GFX hwmod
GFX has a reset status register (PRM_GFX.RM_GFX_RSTST),
so update the GFX hwmod data with .rstst_off and .st_shift
information.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index d1cf3ab..38c7b04 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -329,7 +329,7 @@ static struct omap_hwmod_class
am33xx_gfx_hwmod_class = {
};
static struct omap_hwmod_rst_info am33xx_gfx_resets[] = {
- { .name = gfx, .rst_shift = 0 },
+ { .name = gfx, .rst_shift = 0, .st_shift = 0},
};
static struct omap_hwmod_irq_info am33xx_gfx_irqs[] = {
@@ -347,6 +347,7 @@ static struct omap_hwmod am33xx_gfx_hwmod = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET,
.rstctrl_offs = AM33XX_RM_GFX_RSTCTRL_OFFSET,
+ .rstst_offs = AM33XX_RM_GFX_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
Tony and Paul,
Any Update on this one as well?
Thanks,
Vaibhav
--
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: 3.9 regression : CAM_XCLKA wrong frequency setting.
2013/5/17 jean-philippe francois jp.franc...@cynove.com: Hi, Laurent, you are on the recipient list because the symptom is visible throug your driver. I found the other name looking in the clock related files. Please apologize if you are not concerned by this mail. Symptom : External clock CAM_XCLKA frequency is wrong with 3.9, it was ok until 3.6. Everything else is working fine, except the fps are higher, and the image quality sucks because the input clock is out of spec. Oscilloscope measured freq is around 30 MHz instead of the 24 MHz the sensor is asking for. Hardware : dm3730, with 19.2 MHz crystal, running at OPP100 The register frequency settings seems to be ok, and they are the same as in 3.6.11 : CM_CLKSEL2_PLL : 0x04816807 19, 2 * 360 / 8 = 864 MHz this value is already set when I look at it in u-boot CM_CLKSEL_CAM : 0x5 864 / 5 = 172,8 MHz this value is set through the clock framework by the omap3isp driver code ISP.TCTRL_CTRL : 0x7 172,8 / 7 = 24,685... MHz this value is set by the omap3isp driver code However, as stated before, the actual output frequency is NOT 24 MHz but around 30. If dpll4 frequency is wrong, what other clock would be affected ? As usual, writing a mail brings up new idea. Sorry to use the lists as rubber duck debug partner, but I still need your help. Obviously, dpll4 frequency is correct, because it sources the 96 and 48 MHz clock. I can check it measuring bit time on uart3tx : 8.6usec for 115200 = Ok 30 MHz is 1.25 * 24 MHz CM_CLKSEL_CAM reset value is 4, programmed value is 5, So I did the following, while looking at CAM_XCLKA on scope : # devmem 0x48004f40 0x0005 # devmem 0x48004f40 32 5 - freq = 30 MHz # devmem 0x48004f40 32 4 - freq = 30 MHz # devmem 0x48004f40 32 5 - freq = 24 MHz So there is something nasty in the setup sequence of cam_mclk and dpll4_m5ckx2 that prevents the new divisor value to be used by the hardware. I will dive into the code to see where things went wrong, but I am a bit lost here. What can I do to debug this ? Laurent, I believe you have a camera add-on board for the beagle xm, could you test and report wether you can reproduce this bug ? Attached is the boot log with 3.9, with some debugging messages activated. Thank you for your help, Regards, Jean-Philippe François -- 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/4 v2] mtd:nand:omap2: clean-up of supported ECC schemes
From: Gupta, Pekon pe...@ti.com [Change v1 - v2] added [PATCH 3/4] and [PATCH 4/4] [PATCH 1/4]: clean-up and optimization for supported ECC schemes. [PATCH 2/4]: add separate DT options each supported ECC scheme. [PATCH 3/4]: update BCH4 ECC implementation (using ELM or using lib/bch.h) [PATCH 4/4]: update DT attribute for ti,nand-ecc-opt After this patch series, omap2-nand driver will supports following ECC schemes: +---+---+---+ | ECC scheme|ECC calculation|Error detection| +---+---+---+ |OMAP_ECC_HAMMING_CODE_DEFAULT |S/W|S/W| |OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W| |OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W| +---+---+---+ |OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ - Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires, Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH ECC algorithm. - Selection of OMAP_ECC_BCHx_CODE_HW requires, Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W module. Gupta, Pekon (4): mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe ARM: OMAP2+: cleaned-up DT support of various ECC schemes mtd:nand:omap2: updated support for BCH4 ECC scheme ARM: OMAP2+: updated ECC scheme attributes for omap2-nand DT .../devicetree/bindings/mtd/gpmc-nand.txt | 52 ++- arch/arm/boot/dts/am335x-evm.dts | 2 +- arch/arm/mach-omap2/gpmc.c | 17 +- drivers/mtd/nand/Kconfig | 1 - drivers/mtd/nand/omap2.c | 413 + include/linux/platform_data/elm.h | 4 + include/linux/platform_data/mtd-nand-omap2.h | 22 +- 7 files changed, 253 insertions(+), 258 deletions(-) -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4 v2] ARM: OMAP2+: updated ECC scheme attributes for omap2-nand DT
From: Gupta, Pekon pe...@ti.com
Updates ECC scheme selection string same to same as used in omap2-driver code.
This makes the DT configurations easy to understand and map to actual code.
Signed-off-by: Gupta, Pekon pe...@ti.com
---
.../devicetree/bindings/mtd/gpmc-nand.txt | 47 ++
arch/arm/boot/dts/am335x-evm.dts | 2 +-
arch/arm/mach-omap2/gpmc.c | 19 +
3 files changed, 43 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index de180be..c7a4add 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -25,22 +25,37 @@ Optional properties:
- ti,nand-ecc-opt:Determines the ECC scheme used by driver.
It can be any of the following strings:
- hamming_sw1-bit Hamming ECC using software
-
- hamming_hw1-bit Hamming ECC using hardware
-
- hamming_hw_romcode1-bit Hamming ECC using hardware
- - ECC layout compatible to ROM code
-
- bch8_hw_detection_sw 8-bit BCH with ECC calculation in hardware
- and error detection in software
- - requires Kconfig CONFIG_MTD_NAND_ECC_BCH
-
- bch8_hw 8-bit BCH with ECC calculation in hardware
- and error detection in hardware
- - requires elm_id to be specified
- - requires Kconfig CONFIG_MTD_NAND_OMAP_BCH
-
+ OMAP_ECC_HAMMING_CODE_SW
+ 1-bit Hamming ECC using software.
+
+ OMAP_ECC_HAMMING_CODE_HW
+ 1-bit Hamming ECC using hardware.
+
+ OMAP_ECC_HAMMING_CODE_HW_ROMCODE
+ 1-bit Hamming ECC using hardware with
+ ECC layout compatible to ROM code.
+
+ OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
+ 4-bit BCH with ECC calculation in
+ hardware error detection in software.
+ - requires CONFIG_MTD_NAND_ECC_BCH
+
+ OMAP_ECC_BCH4_CODE_HW
+ 4-bit BCH with ECC calculation in
+ hardware error detection in hardware.
+ - requires CONFIG_MTD_NAND_OMAP_BCH
+ - requires elm_id to be specified
+
+ OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
+ 8-bit BCH with ECC calculation in
+ hardware error detection in software.
+ - requires CONFIG_MTD_NAND_ECC_BCH
+
+ OMAP_ECC_BCH8_CODE_HW
+ 8-bit BCH with ECC calculation in
+ hardware error detection in hardware.
+ - requires CONFIG_MTD_NAND_OMAP_BCH
+ - requires elm_id to be specified
- elm_id: Specifies elm device node. This is required to
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 60e8f59..1107761 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -135,7 +135,7 @@
nand@0,0 {
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 8;
- ti,nand-ecc-opt = bch8_hw;
+ ti,nand-ecc-opt = OMAP_ECC_BCH8_CODE_HW;
gpmc,sync-clk = 0;
gpmc,cs-on = 0;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 03b8027..e3146c3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1205,13 +1205,16 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
#ifdef CONFIG_MTD_NAND
static const char * const nand_ecc_opts[] = {
- [OMAP_ECC_HAMMING_CODE_DEFAULT] = hamming_sw,
- [OMAP_ECC_HAMMING_CODE_HW] = hamming_hw,
- [OMAP_ECC_HAMMING_CODE_HW_ROMCODE] = hamming_hw_romcode,
- [OMAP_ECC_BCH4_CODE_HW] = bch4_hw,
- [OMAP_ECC_BCH4_CODE_HW_DETECTION_SW]= bch4_hw_detection_sw,
- [OMAP_ECC_BCH8_CODE_HW] = bch8_hw,
- [OMAP_ECC_BCH8_CODE_HW_DETECTION_SW]= bch8_hw_detection_sw
+
[PATCH 2/4 v2] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
From: Gupta, Pekon pe...@ti.com
ECC scheme on NAND devices can be implemented in multiple ways.Some using
Software algorithm, while others using in-build Hardware engines.
omap2-nand driver currently supports following flavours of ECC schemes,
selectable via DTB.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAMMING_CODE_DEFAULT |S/W|S/W|
|OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W|
|OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_OMAP_BCH)| | |
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
Selection of some ECC schemes also require enabling following Kconfig options.
This was done to optimize footprint of omap2-nand driver.
-Kconfig:CONFIG_MTD_NAND_ECC_BCHenables S/W based BCH ECC algorithm
-Kconfig:CONFIG_MTD_NAND_OMAP_BCH enables H/W based BCH ECC algorithm
Signed-off-by: Gupta, Pekon pe...@ti.com
---
.../devicetree/bindings/mtd/gpmc-nand.txt | 37 +++---
arch/arm/boot/dts/am335x-evm.dts | 2 +-
arch/arm/mach-omap2/gpmc.c | 12 ---
3 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index e7f8d7e..de180be 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -17,20 +17,35 @@ Required properties:
Optional properties:
- - nand-bus-width: Set this numeric value to 16 if the hardware
- is wired that way. If not specified, a bus
- width of 8 is assumed.
+ - nand-bus-width: Determines data-width of the connected device
+ x16 = 16
+ x8 = 8 (default)
- - ti,nand-ecc-opt:A string setting the ECC layout to use. One of:
- swSoftware method (default)
- hwHardware method
- hw-romcodegpmc hamming mode method romcode layout
- bch4 4-bit BCH ecc code
- bch8 8-bit BCH ecc code
+ - ti,nand-ecc-opt:Determines the ECC scheme used by driver.
+ It can be any of the following strings:
+
+ hamming_sw1-bit Hamming ECC using software
+
+ hamming_hw1-bit Hamming ECC using hardware
+
+ hamming_hw_romcode1-bit Hamming ECC using hardware
+ - ECC layout compatible to ROM code
+
+ bch8_hw_detection_sw 8-bit BCH with ECC calculation in hardware
+ and error detection in software
+ - requires Kconfig CONFIG_MTD_NAND_ECC_BCH
+
+ bch8_hw 8-bit BCH with ECC calculation in hardware
+ and error detection in hardware
+ - requires elm_id to be specified
+ - requires Kconfig CONFIG_MTD_NAND_OMAP_BCH
+
+
+
+ - elm_id: Specifies elm device node. This is required to
+ support some BCH ECC schemes mentioned above.
- - elm_id: Specifies elm device node. This is required to support BCH
- error correction using ELM module.
For inline partiton table parsing (optional):
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0b8f161..60e8f59 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -135,7 +135,7 @@
nand@0,0 {
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 8;
- ti,nand-ecc-opt = bch8;
+ ti,nand-ecc-opt = bch8_hw;
gpmc,sync-clk = 0;
gpmc,cs-on = 0;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 410e1ba..03b8027 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1205,11 +1205,13 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
#ifdef CONFIG_MTD_NAND
[PATCH 3/4 v2] mtd:nand:omap2: updated support for BCH4 ECC scheme
From: Gupta, Pekon pe...@ti.com
This patch adds following two flavours of BCH4 ECC scheme in omap2-nand driver
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
- uses GPMC H/W engine for calculating ECC.
- uses software library (lib/bch.h nand_bch.h) for error correction.
- OMAP_ECC_BCH4_CODE_HW
- uses GPMC H/W engine for calculating ECC.
- uses ELM H/W engine for error correction.
With this patch omap2-nand driver supports following ECC schemes:
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAMMING_CODE_DEFAULT |S/W|S/W|
|OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W|
|OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
Important:
- Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires,
Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH ECC algorithm.
- Selection of OMAP_ECC_BCHx_CODE_HW requires,
Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W module.
Signed-off-by: Gupta, Pekon pe...@ti.com
---
drivers/mtd/nand/Kconfig | 1 -
drivers/mtd/nand/omap2.c | 159 +++
include/linux/platform_data/mtd-nand-omap2.h | 10 +-
3 files changed, 70 insertions(+), 100 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 81bf5e5..b8196a1 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -112,7 +112,6 @@ config MTD_NAND_OMAP_BCH
bool Enable support for hardware BCH error correction
default n
select BCH
- select BCH_CONST_PARAMS
help
Support for hardware BCH error correction.
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 167f8d4..43e4dd4 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -27,6 +27,7 @@
#ifdef CONFIG_MTD_NAND_ECC_BCH
#include linux/bch.h
+#include linux/mtd/nand_bch.h
#endif
#ifdef CONFIG_MTD_NAND_OMAP_BCH
#include linux/platform_data/elm.h
@@ -185,10 +186,9 @@ struct omap_nand_info {
OMAP_NAND_IO_WRITE, /* write */
} iomode;
u_char *buf;
- int buf_len;
+ int buf_len;
struct gpmc_nand_regs reg;
/* fields specific for BCHx_HW ECC scheme */
- struct bch_control *bch;
boolis_elm_used;
struct device *elm_dev;
struct device_node *of_node;
@@ -1227,58 +1227,6 @@ static int omap3_calculate_ecc_bch8(struct mtd_info
*mtd, const u_char *dat,
return 0;
}
-/**
- * omap3_correct_data_bch - Decode received data and correct errors
- * @mtd: MTD device structure
- * @data: page data
- * @read_ecc: ecc read from nand flash
- * @calc_ecc: ecc read from HW ECC registers
- */
-static int omap3_correct_data_bch(struct mtd_info *mtd, u_char *data,
- u_char *read_ecc, u_char *calc_ecc)
-{
- int i, count;
- /* cannot correct more than 8 errors */
- unsigned int errloc[8];
- struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
- mtd);
-
- count = decode_bch(info-bch, NULL, 512, read_ecc, calc_ecc, NULL,
- errloc);
- if (count 0) {
- /* correct errors */
- for (i = 0; i count; i++) {
- /* correct data only, not ecc bytes */
- if (errloc[i] 8*512)
- data[errloc[i]/8] ^= 1 (errloc[i] 7);
- pr_debug(corrected bitflip %u\n, errloc[i]);
- }
- } else if (count 0) {
- pr_err(ecc unrecoverable error\n);
- }
- return count;
-}
-
-/**
- * omap3_free_bch - Release BCH ecc resources
- * @mtd: MTD device structure
- */
-static void omap3_free_bch(struct mtd_info *mtd)
-{
- struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
- mtd);
- if (info-bch) {
- free_bch(info-bch);
- info-bch = NULL;
-
[PATCH 1/4 v2] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe
From: Gupta, Pekon pe...@ti.com
ECC scheme on NAND devices can be implemented in multiple ways.Some using
Software algorithm, while others using in-build Hardware engines.
omap2-nand driver currently supports following flavours of ECC schemes.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAMMING_CODE_DEFAULT |S/W|S/W|
|OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W|
|OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_OMAP_BCH)| | |
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
This patch
- separates the configurations for various ECC schemes.
- fixes dependency issues based on Kconfig options.
- cleans up redundant code
Signed-off-by: Gupta, Pekon pe...@ti.com
---
drivers/mtd/nand/omap2.c | 432 +--
include/linux/platform_data/elm.h| 4 +
include/linux/platform_data/mtd-nand-omap2.h | 22 +-
3 files changed, 224 insertions(+), 234 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 8e820dd..167f8d4 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -25,8 +25,10 @@
#include linux/of.h
#include linux/of_device.h
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
+#ifdef CONFIG_MTD_NAND_ECC_BCH
#include linux/bch.h
+#endif
+#ifdef CONFIG_MTD_NAND_OMAP_BCH
#include linux/platform_data/elm.h
#endif
@@ -141,6 +143,9 @@
#define BCH_ECC_SIZE0 0x0 /* ecc_size0 = 0, no oob protection */
#define BCH_ECC_SIZE1 0x20/* ecc_size1 = 32 */
+#define BADBLOCK_MARKER_LENGTH 0x2
+#define OMAP_ECC_BCH8_POLYNOMIAL 0x201b
+
#ifdef CONFIG_MTD_NAND_OMAP_BCH
static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
0xac, 0x6b, 0xff, 0x99, 0x7b};
@@ -182,14 +187,11 @@ struct omap_nand_info {
u_char *buf;
int buf_len;
struct gpmc_nand_regs reg;
-
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
- struct bch_control *bch;
- struct nand_ecclayout ecclayout;
+ /* fields specific for BCHx_HW ECC scheme */
+ struct bch_control *bch;
boolis_elm_used;
struct device *elm_dev;
struct device_node *of_node;
-#endif
};
/**
@@ -1058,8 +1060,6 @@ static int omap_dev_ready(struct mtd_info *mtd)
}
}
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
-
/**
* omap3_enable_hwecc_bch - Program OMAP3 GPMC to perform BCH ECC correction
* @mtd: MTD device structure
@@ -1141,6 +1141,7 @@ static void omap3_enable_hwecc_bch(struct mtd_info *mtd,
int mode)
writel(ECCCLEAR | ECC1, info-reg.gpmc_ecc_control);
}
+#ifdef CONFIG_MTD_NAND_ECC_BCH
/**
* omap3_calculate_ecc_bch4 - Generate 7 bytes of ECC bytes
* @mtd: MTD device structure
@@ -1227,6 +1228,62 @@ static int omap3_calculate_ecc_bch8(struct mtd_info
*mtd, const u_char *dat,
}
/**
+ * omap3_correct_data_bch - Decode received data and correct errors
+ * @mtd: MTD device structure
+ * @data: page data
+ * @read_ecc: ecc read from nand flash
+ * @calc_ecc: ecc read from HW ECC registers
+ */
+static int omap3_correct_data_bch(struct mtd_info *mtd, u_char *data,
+ u_char *read_ecc, u_char *calc_ecc)
+{
+ int i, count;
+ /* cannot correct more than 8 errors */
+ unsigned int errloc[8];
+ struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
+ mtd);
+
+ count = decode_bch(info-bch, NULL, 512, read_ecc, calc_ecc, NULL,
+ errloc);
+ if (count 0) {
+ /* correct errors */
+ for (i = 0; i count; i++) {
+ /* correct data only, not ecc bytes */
+ if (errloc[i] 8*512)
+ data[errloc[i]/8] ^= 1 (errloc[i] 7);
+ pr_debug(corrected bitflip %u\n, errloc[i]);
+ }
+ } else if (count 0) {
+ pr_err(ecc unrecoverable error\n);
+ }
+ return count;
+}
+
+/**
+ * omap3_free_bch - Release BCH ecc resources
+ * @mtd: MTD device structure
+ */
+static void
[PATCH] usb: musb: fix clock naming
From: Yegor Yefremov yegorsli...@googlemail.com
'ick' was changed to 'hsotgusb_ick'
'fck' was changed to 'hsotgusb_fck'
Signed-off-by: Jan Luebbe j...@pengutronix.de
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
drivers/usb/musb/am35x.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 2231850..92b5b23 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -477,14 +477,14 @@ static int am35x_probe(struct platform_device *pdev)
goto err1;
}
- phy_clk = clk_get(pdev-dev, fck);
+ phy_clk = clk_get(pdev-dev, hsotgusb_ick);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
ret = PTR_ERR(phy_clk);
goto err3;
}
- clk = clk_get(pdev-dev, ick);
+ clk = clk_get(pdev-dev, hsotgusb_fck);
if (IS_ERR(clk)) {
dev_err(pdev-dev, failed to get clock\n);
ret = PTR_ERR(clk);
--
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] broken musb on am35xx
The ick and fck clock names nave been changed. This patch updates these names. Please see this discussion for reference: https://patchwork.kernel.org/patch/1231671/ 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 4/4 v2] ARM: OMAP2+: updated ECC scheme attributes for omap2-nand DT
On Friday 17 May 2013, Gupta, Pekon wrote: From: Gupta, Pekon pe...@ti.com Updates ECC scheme selection string same to same as used in omap2-driver code. This makes the DT configurations easy to understand and map to actual code. Signed-off-by: Gupta, Pekon pe...@ti.com This moves the binding in the wrong direction. First of all, you should never make incompatible changes to a specification document. - bch8_hw_detection_sw 8-bit BCH with ECC calculation in hardware - and error detection in software - - requires Kconfig CONFIG_MTD_NAND_ECC_BCH The binding before your change is already broken since it refers to Linux-specific Kconfig symbols, and you fail to fix that. + OMAP_ECC_BCH4_CODE_HW_DETECTION_SW + 4-bit BCH with ECC calculation in + hardware error detection in software. + - requires CONFIG_MTD_NAND_ECC_BCH Instead you make it worse by using /more/ Linux-isms in the binding. 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
[PATCH v5] ARM:dts:omap4-panda: Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v5 - Provide pincrtl phandle to the gpio-led driver
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 -
arch/arm/boot/dts/omap4-panda-es.dts | 34 +
2 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..5fd59b3 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = 0x8000 0x4000; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
heartbeat {
label = pandaboard::status1;
gpios = gpio1 7 0;
@@ -137,6 +142,15 @@
};
};
+omap4_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..08d2e38 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,37 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+omap4_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins =
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
+led_wkgpio_pins {
+ pinctrl-single,pins =
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+};
+
+leds {
+ compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_gpio_pins
+ led_wkgpio_pins
+ ;
+
+ heartbeat {
+ label = pandaboard::status1;
+ gpios = gpio4 14 0;
+ linux,default-trigger = heartbeat;
+ };
+ mmc {
+ label = pandaboard::status2;
+ gpios = gpio1 8 0;
+ linux,default-trigger = mmc0;
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/4] arm: omap: remove using usb_bind_phy for binding musb and phy
Now that MUSB for OMAP started using devm_usb_get_phy_by_name which does not require PHY library to already have the binding information, removed usb_bind_phy calls that binds the MUSB controller with the PHY from the board files. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c |1 - arch/arm/mach-omap2/board-3430sdp.c |1 - arch/arm/mach-omap2/board-4430sdp.c |1 - arch/arm/mach-omap2/board-cm-t35.c |1 - arch/arm/mach-omap2/board-devkit8000.c |1 - arch/arm/mach-omap2/board-igep0020.c |1 - arch/arm/mach-omap2/board-ldp.c |1 - arch/arm/mach-omap2/board-omap3beagle.c |1 - arch/arm/mach-omap2/board-omap3evm.c |1 - arch/arm/mach-omap2/board-omap3logic.c |1 - arch/arm/mach-omap2/board-omap3pandora.c |1 - arch/arm/mach-omap2/board-omap3stalker.c |1 - arch/arm/mach-omap2/board-omap3touchbook.c |1 - arch/arm/mach-omap2/board-omap4panda.c |1 - arch/arm/mach-omap2/board-overo.c|1 - arch/arm/mach-omap2/board-rm680.c|1 - arch/arm/mach-omap2/board-rx51.c |1 - arch/arm/mach-omap2/board-zoom-peripherals.c |1 - 18 files changed, 18 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 244d8a5..30d81f2 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -233,7 +233,6 @@ static void __init omap_2430sdp_init(void) omap_hsmmc_init(mmc); omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA | OMAP_PULL_UP); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); board_smc91x_init(); diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index 23b004a..7f431b4 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -590,7 +590,6 @@ static void __init omap_3430sdp_init(void) omap_ads7846_init(1, gpio_pendown, 310, NULL); omap_serial_init(); omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); board_smc91x_init(); board_flash_init(sdp_flash_partitions, chip_sel_3430, 0); diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 56a9a4f..5a05b5a 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -730,7 +730,6 @@ static void __init omap_4430sdp_init(void) omap4_sdp4430_wifi_init(); omap4_twl6030_hsmmc_init(mmc); - usb_bind_phy(musb-hdrc.2.auto, 0, omap-usb2.3.auto); usb_musb_init(musb_board_data); status = omap_ethernet_init(); diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index ee6218c..f9b4241 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -690,7 +690,6 @@ static void __init cm_t3x_common_init(void) cm_t35_init_display(); omap_twl4030_audio_init(cm-t3x, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); cm_t35_init_usbh(); cm_t35_init_camera(); diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c index 5764205..8d24aab 100644 --- a/arch/arm/mach-omap2/board-devkit8000.c +++ b/arch/arm/mach-omap2/board-devkit8000.c @@ -593,7 +593,6 @@ static void __init devkit8000_init(void) omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); usbhs_init(usbhs_bdata); board_nand_init(devkit8000_nand_partitions, diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c index b54562d..5451c9c 100644 --- a/arch/arm/mach-omap2/board-igep0020.c +++ b/arch/arm/mach-omap2/board-igep0020.c @@ -628,7 +628,6 @@ static void __init igep_init(void) omap_serial_init(); omap_sdrc_init(m65kam_sdrc_params, m65kam_sdrc_params); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); igep_flash_init(); diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c index d0d17bc..07423f2 100644 --- a/arch/arm/mach-omap2/board-ldp.c +++ b/arch/arm/mach-omap2/board-ldp.c @@ -376,7 +376,6 @@ static void __init omap_ldp_init(void) omap_ads7846_init(1, 54, 310, NULL); omap_serial_init(); omap_sdrc_init(NULL, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); board_nand_init(ldp_nand_partitions, ARRAY_SIZE(ldp_nand_partitions), ZOOM_NAND_CS, 0, nand_default_timings); diff --git
[RFC PATCH 3/4] usb: musb: omap: use the new API to get PHY reference by label
After the devices are created using PLATFORM_DEVID_AUTO,
devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably
as it relies on the device_names passed in usb_bind_phy. So used the
new API devm_usb_get_phy_by_name to get the PHY reference.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/musb_core.c |1 +
drivers/usb/musb/musb_core.h |1 +
drivers/usb/musb/omap2430.c |2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 37a261a..00fbaf4 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1864,6 +1864,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
musb-board_set_power = plat-set_power;
musb-min_power = plat-min_power;
musb-ops = plat-platform_ops;
+ musb-phy_name = plat-phy_name;
/* The musb_platform_init() call:
* - adjusts musb-mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..e9a9339 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -434,6 +434,7 @@ struct musb {
unsigneddouble_buffer_not_ok:1;
struct musb_hdrc_config *config;
+ const char *phy_name;
#ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 3551f1a..be29aa7 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -352,7 +352,7 @@ static int omap2430_musb_init(struct musb *musb)
musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
usb-phy, 0);
else
- musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+ musb-xceiv = devm_usb_get_phy_by_name(dev, musb-phy_name);
if (IS_ERR(musb-xceiv)) {
status = PTR_ERR(musb-xceiv);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy label) should be added in the platform
data of the controller.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |6 +-
include/linux/usb/musb.h |3 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..5ddbe39 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+ musb_plat.phy_name = omap-usb2;
+ } else if (cpu_is_omap34xx()) {
+ musb_plat.phy_name = twl4030;
+ }
if (soc_is_am35xx()) {
oh_name = am35x_otg_hs;
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..c05d46d 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
/* for clk_get() */
const char *clock;
+ /* phy device label */
+ const char *phy_name;
+
/* (HOST or OTG) switch VBUS on/off */
int (*set_vbus)(struct device *dev, int is_on);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/4] usb: phy: add a new API to get PHY ref by label
After the devices are created using PLATFORM_DEVID_AUTO,
devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably
as it relies on the device_names passed in usb_bind_phy. So
added a new API to get the PHY reference by PHY label (PHY label
should be filled which creating the PHY).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/phy/phy.c | 78 +++
include/linux/usb/phy.h | 16 ++
2 files changed, 94 insertions(+)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index a9984c7..0dfdc38 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -55,6 +55,21 @@ static struct usb_phy *__usb_find_phy_dev(struct device *dev,
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__usb_find_phy_by_name(struct device *dev,
+ struct list_head *list, const char *name)
+{
+ struct usb_phy *phy = NULL;
+
+ list_for_each_entry(phy, list, head) {
+ if (strcmp(name, phy-label))
+ continue;
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static struct usb_phy *__of_usb_find_phy(struct device_node *node)
{
struct usb_phy *phy;
@@ -272,6 +287,69 @@ struct usb_phy *devm_usb_get_phy_dev(struct device *dev,
u8 index)
EXPORT_SYMBOL_GPL(devm_usb_get_phy_dev);
/**
+ * usb_get_phy_by_name - find the USB PHY using device ptr and phy label
+ * @dev - device that requests this phy
+ * @name - the name of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy. The caller is responsible for
+ * calling usb_put_phy() to release that count.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *usb_get_phy_by_name(struct device *dev, const char *name)
+{
+ struct usb_phy *phy = NULL;
+ unsigned long flags;
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __usb_find_phy_by_name(dev, phy_list, name);
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
+ pr_err(unable to find transceiver\n);
+ goto err0;
+ }
+
+ get_device(phy-dev);
+
+err0:
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(usb_get_phy_by_name);
+
+/**
+ * devm_usb_get_phy_by_name - find the USB PHY using device ptr and phy label
+ * @dev - device that requests this phy
+ * @name - the label of the phy
+ *
+ * Gets the phy using usb_get_phy_by_name(), and associates a device with it
+ * using devres. On driver detach, release function is invoked on the devres
+ * data, then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_by_name(struct device *dev, const char *name)
+{
+ struct usb_phy **ptr, *phy;
+
+ ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ phy = usb_get_phy_by_name(dev, name);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(devm_usb_get_phy_by_name);
+
+/**
* devm_usb_put_phy - release the USB PHY
* @dev - device that wants to release this phy
* @phy - the phy returned by devm_usb_get_phy()
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..12fa4b1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -188,6 +188,10 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type);
extern struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index);
extern struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index);
+extern struct usb_phy *usb_get_phy_by_name(struct device *dev,
+ const char *name);
+extern struct usb_phy *devm_usb_get_phy_by_name(struct device *dev,
+ const char *name);
extern struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
const char *phandle, u8 index);
extern void usb_put_phy(struct usb_phy *);
@@ -216,6 +220,18 @@ static inline struct usb_phy *devm_usb_get_phy_dev(struct
device *dev, u8 index)
return ERR_PTR(-ENXIO);
}
+static inline struct usb_phy *usb_get_phy_by_name(struct device *dev,
+ const char *name)
+{
+ return ERR_PTR(-ENXIO);
+}
+
+static inline struct usb_phy *devm_usb_get_phy_by_name(struct device *dev,
+ const char *name)
+{
+ return ERR_PTR(-ENXIO);
+}
+
static inline struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
const char *phandle, u8 index)
{
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 08:21-20130517, Dan Murphy wrote:
[...]
May be others with better DT experience can help here..
but here is a trick to reduce dts file changes:
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..08d2e38 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,37 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+omap4_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins =
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
+led_wkgpio_pins {
+ pinctrl-single,pins =
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+};
+
+leds {
+ compatible = gpio-leds;
+ pinctrl-names = default;
Normally, override will either add (if new param) OR replace (if same param)
So the above two are superfluous.
+ pinctrl-0 =
+ led_gpio_pins
+ led_wkgpio_pins
+ ;
These are needed
+
+ heartbeat {
+ label = pandaboard::status1;
can drop this
+ gpios = gpio4 14 0;
needed
+ linux,default-trigger = heartbeat;
can be dropped
+ };
+ mmc {
+ label = pandaboard::status2;
could be dropped
+ gpios = gpio1 8 0;
needed
+ linux,default-trigger = mmc0;
could be dropped.
--
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: reset handling in am335x hwmod data
Hi,
On Sun, Dec 23, 2012 at 08:58:13PM +, Paul Walmsley wrote:
In this specific case the pin is connected to nCONFIG of a FPGA. The
FPGA is commanded to start configuration from a SPI flash in the
bootloader, so it can happen in parallel with kernel
load/uncompress/startup, but as the kernel resets the gpio during
initialization this doesn't work.
Digging a bit into it, I see the hwmod of the gpio controller is
configured to reset at startup, and it works correctly (E.G. the pin is
left asserted) if I change it to HWMOD_INIT_NO_RESET:
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
.name = gpio2,
.class = am33xx_gpio_hwmod_class,
.clkdm_name = l4ls_clkdm,
- .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
.mpu_irqs = am33xx_gpio1_irqs,
.main_clk = l4ls_gclk,
.prcm = {
Now the question is why is this configured like this?
This behavior is intended to decouple the kernel from the bootloader, or
previously-booted operating system (e.g., the kexec case). The original
goal was to place the system in an known safe state as soon as possible
after the kernel starts. This is to prevent misconfigured or
there is one issue with this. At least on AM335x starter kit, GPIO0_7
is used as DDR power pin. If we reset that GPIO bank, DDR looses power
and for obscure reasons (:-)) the board doesn't boot.
In this case, we cannot reset that bank, otherwise Starter Kit will
never boot in mainline. Bad PCB design, I know, but it's not something
we can change now :-)
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] i2c: busses: remove superfluous comment
On Fri, May 17, 2013 at 11:53:23AM +0200, Wolfram Sang wrote: The comment already got copypasted around and is not really useful. Remove it. Signed-off-by: Wolfram Sang w...@the-dreams.de FWIW on i2c-omap.c: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: reset handling in am335x hwmod data
Felipe == Felipe Balbi ba...@ti.com writes:
Hi,
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
.name = gpio2,
.class = am33xx_gpio_hwmod_class,
.clkdm_name = l4ls_clkdm,
- .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
.mpu_irqs = am33xx_gpio1_irqs,
.main_clk = l4ls_gclk,
.prcm = {
Now the question is why is this configured like this?
This behavior is intended to decouple the kernel from the bootloader, or
previously-booted operating system (e.g., the kexec case). The original
goal was to place the system in an known safe state as soon as possible
after the kernel starts. This is to prevent misconfigured or
Felipe there is one issue with this. At least on AM335x starter kit,
Felipe GPIO0_7 is used as DDR power pin. If we reset that GPIO bank,
Felipe DDR looses power and for obscure reasons (:-)) the board
Felipe doesn't boot.
Heh!
Felipe In this case, we cannot reset that bank, otherwise Starter Kit
Felipe will never boot in mainline. Bad PCB design, I know, but it's
Felipe not something we can change now :-)
Indeed. So that's two examples of people designing boards with the
assumption that gpios will not toggle between bootloader and running
system. Chances are that there will be others.
--
Bye, Peter Korsgaard
--
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/6] ARM: OMAP2+: hwmod and SERIAL: Remove sysc handling from driver
Hi Paul, Paul Walmsley p...@pwsan.com writes: On Wed, 15 May 2013, Rajendra Nayak wrote: OMAP UART IP needs manual idle modes based on functional state of the IP. Currently this is handled by the driver with function pointers implemented in platform code. This however breaks in case of device tree because of missing idle handling. The series tries to address the issue and tries to remove complete sysc handling from serial driver. These look good to me. Will queue them for v3.10-rc once they pass local testing here. I reviewed and tested v2 of this (Rajendra forgot to add the tags in v3) and also just sanity tested v3 of this on 4430/panda DT boot to verify the console issue is resolved. Feel free to add: Reviewed-by: Kevin Hilman khil...@linaro.org Tested-by: Kevin Hilman khil...@linaro.org # OMAP4/Panda Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM : omap3 : fix wrong container_of in clock36xx.c
omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of the clock
to be a clk_hw_omap. However, looking at cclock3xxx_data.c, all concerned clock
have parent defined as clk_divider.
Fix the function to use clk_divider.
Tested with 3.9 on dm3730.
Signed-off-by: Jean-Philippe François jp.franc...@cynove.com
Index: b/arch/arm/mach-omap2/clock36xx.c
===
--- a/arch/arm/mach-omap2/clock36xx.c
+++ b/arch/arm/mach-omap2/clock36xx.c
@@ -20,11 +20,12 @@
#include linux/kernel.h
#include linux/clk.h
+#include linux/clk-provider.h
#include linux/io.h
#include clock.h
#include clock36xx.h
-
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
/**
* omap36xx_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
@@ -39,29 +40,28 @@
*/
int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk_hw *clk)
{
- struct clk_hw_omap *parent;
+ struct clk_divider *parent;
struct clk_hw *parent_hw;
- u32 dummy_v, orig_v, clksel_shift;
+ u32 dummy_v, orig_v;
int ret;
/* Clear PWRDN bit of HSDIVIDER */
ret = omap2_dflt_clk_enable(clk);
parent_hw = __clk_get_hw(__clk_get_parent(clk-clk));
- parent = to_clk_hw_omap(parent_hw);
+ parent = to_clk_divider(parent_hw);
/* Restore the dividers */
if (!ret) {
- clksel_shift = __ffs(parent-clksel_mask);
- orig_v = __raw_readl(parent-clksel_reg);
+ orig_v = __raw_readl(parent-reg);
dummy_v = orig_v;
/* Write any other value different from the Read value */
- dummy_v ^= (1 clksel_shift);
- __raw_writel(dummy_v, parent-clksel_reg);
+ dummy_v ^= (1 parent-shift);
+ __raw_writel(dummy_v, parent-reg);
/* Write the original divider */
- __raw_writel(orig_v, parent-clksel_reg);
+ __raw_writel(orig_v, parent-reg);
}
return ret;
--
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 v6] ARM:dts:omap4-panda: Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
Changes in this version:
- review comments incorporated.
Previous version of this patch was discussed in:
https://patchwork.kernel.org/patch/2582771/
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..5fd59b3 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = 0x8000 0x4000; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
heartbeat {
label = pandaboard::status1;
gpios = gpio1 7 0;
@@ -137,6 +142,15 @@
};
};
+omap4_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..c968a3b 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+omap4_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins =
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
+led_wkgpio_pins {
+ pinctrl-single,pins =
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+};
+
+leds {
+ pinctrl-0 =
+ led_gpio_pins
+ led_wkgpio_pins
+ ;
+
+ heartbeat {
+ gpios = gpio4 14 0;
+ };
+ mmc {
+ gpios = gpio1 8 0;
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 11:02-20130517, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
Changes in this version:
- review comments incorporated.
Previous version of this patch was discussed in:
https://patchwork.kernel.org/patch/2582771/
one minor nit,
$subject could do with space after the ':'
otherwise, it looks fine to me. Will suggest waiting for further
reviewers if they have an opinion prior to a new rev.
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..5fd59b3 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = 0x8000 0x4000; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
heartbeat {
label = pandaboard::status1;
gpios = gpio1 7 0;
@@ -137,6 +142,15 @@
};
};
+omap4_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..c968a3b 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+omap4_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins =
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
+led_wkgpio_pins {
+ pinctrl-single,pins =
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+};
+
+leds {
+ pinctrl-0 =
+ led_gpio_pins
+ led_wkgpio_pins
+ ;
+
+ heartbeat {
+ gpios = gpio4 14 0;
+ };
+ mmc {
+ gpios = gpio1 8 0;
+ };
+};
--
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 v6] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 05/17/2013 11:15 AM, Nishanth Menon wrote:
On 11:02-20130517, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
Changes in this version:
- review comments incorporated.
Previous version of this patch was discussed in:
https://patchwork.kernel.org/patch/2582771/
one minor nit,
$subject could do with space after the ':'
otherwise, it looks fine to me. Will suggest waiting for further
reviewers if they have an opinion prior to a new rev.
Thanks NM I will queue up this change locally and await further review prior to
sending v7.
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..5fd59b3 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = 0x8000 0x4000; /* 1 GB */
};
-leds {
+leds: leds {
compatible = gpio-leds;
+pinctrl-names = default;
+pinctrl-0 =
+led_wkgpio_pins
+;
+
heartbeat {
label = pandaboard::status1;
gpios = gpio1 7 0;
@@ -137,6 +142,15 @@
};
};
+omap4_pmx_wkup {
+led_wkgpio_pins: pinmux_leds_wkpins {
+pinctrl-single,pins =
+0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+;
+};
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..c968a3b 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+omap4_pmx_core {
+led_gpio_pins: gpio_led_pmx {
+pinctrl-single,pins =
+0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+;
+};
+};
+
+led_wkgpio_pins {
+pinctrl-single,pins =
+0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+;
+};
+
+leds {
+pinctrl-0 =
+led_gpio_pins
+led_wkgpio_pins
+;
+
+heartbeat {
+gpios = gpio4 14 0;
+};
+mmc {
+gpios = gpio1 8 0;
+};
+};
--
--
Dan Murphy
--
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: am3517: failed to boot 3.10-rc1
Yegor Yefremov yegor_s...@visionsystems.de writes: On 15.05.2013 10:37, Yegor Yefremov wrote: On 14.05.2013 15:01, Yegor Yefremov wrote: On 14.05.2013 14:52, Felipe Balbi wrote: On Tue, May 14, 2013 at 11:24:44AM +0200, Yegor Yefremov wrote: Trying to boot 3.10-rc1 on an am3515 based board. With the same .config as 3.7 the system comes to RTC stops there. I've also tried make omap2plus_defconfig with no visible difference. I'm booting from MMC card and it will be detected by the system. Kernel is from http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git, latest commit f722406faae2d073cc1d01063d1123c35425939e. Are there any pending patches needed to boot on am3517? does v3.9 work ? Can you bisect ? 'git checkout v3.9' version is working, will try to bisect. This is bisect's result: f7b861b7a6d9d1838cbbb5f4053e61578b86d134 is the first bad commit commit f7b861b7a6d9d1838cbbb5f4053e61578b86d134 Author: Thomas Gleixner t...@linutronix.de Date: Thu Mar 21 22:49:38 2013 +0100 arm: Use generic idle loop Use the generic idle loop and replace enable/disable_hlt with the respective core functions. Signed-off-by: Thomas Gleixner t...@linutronix.de Cc: Linus Torvalds torva...@linux-foundation.org Cc: Rusty Russell ru...@rustcorp.com.au Cc: Paul McKenney paul...@linux.vnet.ibm.com Cc: Peter Zijlstra pet...@infradead.org Reviewed-by: Cc: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Cc: Magnus Damm magnus.d...@gmail.com Cc: Russell King li...@arm.linux.org.uk Tested-by: Kevin Hilman khil...@linaro.org # OMAP Link: http://lkml.kernel.org/r/20130321215233.826238...@linutronix.de :04 04 887517403888ff3947bce216aa4c1ff3ce3af434 8dc5236688a80fc64fa4112ce6136ecf3a19bac9 M arch We had such a problem long ago (https://patchwork.kernel.org/patch/1220061/ and http://www.spinics.net/lists/arm-kernel/msg168865.html) and the workaround was to use hohlt in kernel parameters. But with this patch the nohlt has gone. So now we need a solution, that fixes the root of the problem. The broken 'nohlt' feature was indeed a regression caused by the above patch, but there's already a fix queued for v3.10-rc2[1], so -rc1 will need the patch applied manually. Kevin [1] https://lkml.org/lkml/2013/5/5/6 -- 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: reset handling in am335x hwmod data
Felipe Balbi ba...@ti.com writes:
Hi,
On Sun, Dec 23, 2012 at 08:58:13PM +, Paul Walmsley wrote:
In this specific case the pin is connected to nCONFIG of a FPGA. The
FPGA is commanded to start configuration from a SPI flash in the
bootloader, so it can happen in parallel with kernel
load/uncompress/startup, but as the kernel resets the gpio during
initialization this doesn't work.
Digging a bit into it, I see the hwmod of the gpio controller is
configured to reset at startup, and it works correctly (E.G. the pin is
left asserted) if I change it to HWMOD_INIT_NO_RESET:
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
.name = gpio2,
.class = am33xx_gpio_hwmod_class,
.clkdm_name = l4ls_clkdm,
- .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
.mpu_irqs = am33xx_gpio1_irqs,
.main_clk = l4ls_gclk,
.prcm = {
Now the question is why is this configured like this?
This behavior is intended to decouple the kernel from the bootloader, or
previously-booted operating system (e.g., the kexec case). The original
goal was to place the system in an known safe state as soon as possible
after the kernel starts. This is to prevent misconfigured or
there is one issue with this. At least on AM335x starter kit, GPIO0_7
is used as DDR power pin. If we reset that GPIO bank, DDR looses power
and for obscure reasons (:-)) the board doesn't boot.
In this case, we cannot reset that bank, otherwise Starter Kit will
never boot in mainline. Bad PCB design, I know, but it's not something
we can change now :-)
FWIW, we've seen this before (GPIO connected to PMIC reset is a fun
one), and this is why we have omap_hwmod_no_setup_reset().
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
* Hiremath, Vaibhav hvaib...@ti.com [130517 03:36]: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, March 27, 2013 11:15 PM To: Tony Lindgren; Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Nayak, Rajendra Subject: Re: [PATCH-V2] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock On Wed, 27 Mar 2013, Vaibhav Hiremath wrote: It is required to enable respective clock-domain before enabling any clock/module inside that clock-domain. During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so it will be disabled even if childs of this clock-domain is enabled, which keeps child modules in idle mode. This fixes the kernel crash observed on AM335xEVM-SK platform, where clkdiv32_ick clock is being used as a gpio debounce clock and since clkdiv32k_ick is in idle mode it leads to below crash - Crash Log: == [2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa1ac150 [2.606434] Internal error: : 1028 [#1] SMP ARM [2.611207] Modules linked in: [2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4) [2.620973] PC is at _set_gpio_debounce+0x60/0x104 [2.626025] LR is at clk_enable+0x30/0x3c Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Tony, if it isn't too late, could this one be added to your 3.9-rc fixes series? Looks like we missed this so far. Tony, can you merge this patch for v3.10-rc ? Oops, sorry somehow this did not make it. I'll apply it to omap-for-v3.10/fixes with cc: stable flag. 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: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
* Santosh Shilimkar santosh.shilim...@ti.com [130517 01:02]: Paul, Tony, On Friday 05 April 2013 10:20 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]: [..] Can't we already trim the am33xx hwmod data after your patches for v3.10 as am33xx is already DT only? Unfortunately we cannot create negative diffstat in other ways for v3.10 merge window as we cannot make omap4 DT only just quite yet. Yes we can and I can take a stab it tomorrow. The only thing is I might need some support for testing but thats manageable. Will take a stab at it tomorrow and if everything goes well, post a patch for smae. Patch for the AM33XX to trim is end of the email. Thanks to Sricharan and Pekon for patch and testing. Looping both Vaibhav's if they have any objection on the patch. Regards, Santosh From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file For whatever reason, we again missed the merge window for the subject series, I would like to know your plan on the subject series for at least 3.11. Asking *well in advance* to avoid late merge related discussions. Yes, I think we should have now a omap5 hwmod data sized hole coming up with conversion of omap4 to be DT only. I'll post those patches today for the board file and legacy mux removal for omap4: 12 files changed, 52 insertions(+), 3260 deletions(-) Those coupled with your am33xx hwmod cleanup patch and your omap4 hwmod cleanup patch should allow us having the omap5 hwmod data without making the diffstats look too bad. Thanks to Vaibhav, AM33XX patch is tested and validated with some updates considering upcoming PM support for AM33XX. So that patch will be included in the series. Rajendra will follow up the patchset if there is some re-basing is needed since I will away for few weeks because of travel. OK, well the omap4 hwmod clean-up patch depends on first dropping the above mentioned omap4 legacy files. OMAP5 data is the *only* thing which is gating the device to boot from mainline. That's great! 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: OMAP4: change the device names in usb_bind_phy
* Kishon Vijay Abraham I kis...@ti.com [130516 22:45]: Hi, On Thursday 16 May 2013 09:50 PM, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@iki.fi [130516 09:11]: On 16/05/13 18:58, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@iki.fi [130515 03:59]: Just checking.. Do you have CONFIG_OMAP_OCP2SCP=y in your .config? Sounds like the some transceivers should depend on that for omap4. Yes, I have OCP2SCP=y. Hmm well no idea beyond that then. Sounds like Kishon should check it. The musb-hdrc id is wrong on overo also. Hmm has there been a fix posted for that? I couldn't find with a quick look. We debugged and discussed this on an irc channel with Kishon, who said he'll send a patch. Changing the musb-hdrc ID on overo fixed the issue, and it looks very similar to the error on 4430sdp. The overo fix was just: hmm.. I think using device name to bind the controller and the phy can no longer be used reliably. I think it's better to have something like what Grant suggested in my other patch series.. to have the phy reference into the host controllers platform_data structure. And for the phy reference I'll have label and id. Does this makes sense to you? Sounds OK to me, but I guess that would be for v3.11. I think we still need a fix for at least overo for v3.10? 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: OMAP2+: AM33xx: Add missing reset status info to GFX hwmod
* Hiremath, Vaibhav hvaib...@ti.com [130517 04:13]:
-Original Message-
From: Hiremath, Vaibhav
Sent: Sunday, May 05, 2013 12:18 AM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; linux-arm-ker...@lists.infradead.org; Hiremath,
Vaibhav; Paul Walmsley
Subject: [PATCH] ARM: OMAP2+: AM33xx: Add missing reset status info to
GFX hwmod
GFX has a reset status register (PRM_GFX.RM_GFX_RSTST),
so update the GFX hwmod data with .rstst_off and .st_shift
information.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index d1cf3ab..38c7b04 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -329,7 +329,7 @@ static struct omap_hwmod_class
am33xx_gfx_hwmod_class = {
};
static struct omap_hwmod_rst_info am33xx_gfx_resets[] = {
- { .name = gfx, .rst_shift = 0 },
+ { .name = gfx, .rst_shift = 0, .st_shift = 0},
};
static struct omap_hwmod_irq_info am33xx_gfx_irqs[] = {
@@ -347,6 +347,7 @@ static struct omap_hwmod am33xx_gfx_hwmod = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET,
.rstctrl_offs = AM33XX_RM_GFX_RSTCTRL_OFFSET,
+ .rstst_offs = AM33XX_RM_GFX_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
Tony and Paul,
Any Update on this one as well?
Is this needed for v3.10 as a fix? If so, it should describe the
regression or error.
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: reset handling in am335x hwmod data
Kevin == Kevin Hilman khil...@linaro.org writes: In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-) Kevin FWIW, we've seen this before (GPIO connected to PMIC reset is a Kevin fun one), and this is why we have omap_hwmod_no_setup_reset(). Yes, but there's no dts bindings for this, and from a quick test the reset handling happens before the device tree is probed. -- Bye, Peter Korsgaard -- 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: reset handling in am335x hwmod data
On 20:10-20130517, Peter Korsgaard wrote: Kevin == Kevin Hilman khil...@linaro.org writes: In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-) Kevin FWIW, we've seen this before (GPIO connected to PMIC reset is a Kevin fun one), and this is why we have omap_hwmod_no_setup_reset(). Yes, but there's no dts bindings for this, and from a quick test the reset handling happens before the device tree is probed. I have the same issue with TPS62361 on Palmas - GPIO controls the voltage register supplying MPU, without any driver setting things up, GPIO gets reset and obviously voltage value switches to an voltage where device does not function. Solution I am working on to solve this is [1]: snippet is part of a patch that I am working on atm. This is the right way to do it IMHO. Will allow the driver to exist when HWMOD will be eventually replaced by some other framework. [1]: http://pastebin.com/XPmAB1Zb -- 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: v3.10-rc1: backlight brightness after boot on N900
On Thu, May 16, 2013 at 07:52:12AM +0300, Tomi Valkeinen wrote: On 15/05/13 20:18, Aaro Koskinen wrote: Is it expected that after boot you get 0 brightness i.e. a seemingly blank display on N900 with 3.10-rc1? There were some small changes merged in v3.10 related to acx's backlight, but they were removing dead code so I don't see how those could affect... [...] So what comes to my mind is that either the model is detected wrong, or the acx565akm_get_actual_brightness() which reads the current BL from the panel happens to return 0, either because of an error, or because the bootloader has set the BL to 0. But why either of those would've changed with v3.10... No idea... The panel is detected and probed correctly. So something else is wrong. It's not a bootloader issue, because booting 3.9 right after 3.10-rc1 makes the display work again correctly. So I bisected and it points to: commit a2797beadfcb5a0974a30929b613b4d1adb023d1 Author: Jon Hunter jon-hun...@ti.com Date: Thu Apr 4 15:16:15 2013 -0500 gpio/omap: force restore if context loss is not detectable When I revert that commit from 3.10-rc1, the display works again as expected. 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: v3.10-rc1: backlight brightness after boot on N900
* Aaro Koskinen aaro.koski...@iki.fi [130517 11:30]: On Thu, May 16, 2013 at 07:52:12AM +0300, Tomi Valkeinen wrote: On 15/05/13 20:18, Aaro Koskinen wrote: Is it expected that after boot you get 0 brightness i.e. a seemingly blank display on N900 with 3.10-rc1? There were some small changes merged in v3.10 related to acx's backlight, but they were removing dead code so I don't see how those could affect... [...] So what comes to my mind is that either the model is detected wrong, or the acx565akm_get_actual_brightness() which reads the current BL from the panel happens to return 0, either because of an error, or because the bootloader has set the BL to 0. But why either of those would've changed with v3.10... No idea... The panel is detected and probed correctly. So something else is wrong. It's not a bootloader issue, because booting 3.9 right after 3.10-rc1 makes the display work again correctly. So I bisected and it points to: commit a2797beadfcb5a0974a30929b613b4d1adb023d1 Author: Jon Hunter jon-hun...@ti.com Date: Thu Apr 4 15:16:15 2013 -0500 gpio/omap: force restore if context loss is not detectable When I revert that commit from 3.10-rc1, the display works again as expected. OK that should be fixed by ab6ec0fb (gpio/omap: ensure gpio context is initialised) in linux-next. Can you check if that helps? Looks like it has not yet been merged to mainline tree. Linus W, any news on when you might be sending that fix upstream? 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: OMAP3: Fix iva2_pwrdm settings for 3703
On Thu, May 16, 2013 at 11:35:16AM -0700, Tony Lindgren wrote: * Yegor Yefremov yegor_s...@visionsystems.de [130516 05:13]: On 15.05.2013 23:50, Mark A. Greer wrote: On Wed, May 15, 2013 at 10:07:35AM -0700, Tony Lindgren wrote: * Mark A. Greer mgr...@animalcreek.com [130514 18:57]: On Tue, May 14, 2013 at 05:25:37PM -0700, Tony Lindgren wrote: Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states. Signed-off-by: Tony Lindgren t...@atomide.com --- Paul Kevin, do you have better ideas for fixing this? --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void) /* Clear any pending PRCM interrupts */ omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); - if (omap3_has_iva()) - omap3_iva_idle(); + /* + * We need to idle iva2_pwrdm even on am3703 with no iva2. + */ + omap3_iva_idle(); omap3_d2d_idle(); } [Kevin, Paul, some background: Tony discovered that the am3703 needs to have omap3_iva_idle() called even though its not supposed to have an IVA.] This is potentially bad for other SoC's that don't have an IVA so I don't think its the way to go. My preference would be to set the OMAP3_HAS_IVA flag for the am3703 only since its the one with the bug. Maybe something in id.c:omap3xxx_check_features() but I don't see any existing way to check for an am3703 vs. other am37xx SoCs. Any ideas? Another option, I suppose, is a dts entry but I don't like that at all. It seems that iva2_pwrdm is there for all omap3 even if OMAP3_HAS_IVA flag is unset. And if that's the case, iva2 clocks still need to be idled in all cases. Ahh, this takes us to the Great TI Docs Mystery :) -- its basically impossible to tell because despite what their docs may say, the hardware can be quite different. I'm not sure how to proceed other than trial error with as many different SoCs as we can find. It's possible that not all steps in omap3_iva_idle() are needed though. I can debug further to see which part of the omap3_iva_idle() are needed. Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with? I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days). I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out. I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903 I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html OK sounds like Mark's patch as http://www.spinics.net/lists/arm-kernel/msg168865.html is needed as a fix. FYI, that patch works (until recently, anyway) but is an unacceptable approach. I have such a system running, so if you have any other patches/ideas to test, I would do it. Well I think my patch does not matter for am3517 as that one has iva2 while am3703 does not. To make sure there is no confusion, the am3517 does NOT have an iva2. Tony was misled by a boot log from an older kernel that didn't have the patch that unsets the IVA feature flag. Aside: I have so far been unable to get my am3517evm to come up. Mark -- -- 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: OMAP3: Fix iva2_pwrdm settings for 3703
On Thu, May 16, 2013 at 12:19:20PM +0200, Yegor Yefremov wrote: On 15.05.2013 23:50, Mark A. Greer wrote: On Wed, May 15, 2013 at 10:07:35AM -0700, Tony Lindgren wrote: Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with? I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days). I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out. I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903 I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html I have such a system running, so if you have any other patches/ideas to test, I would do it. Yegor, since I've so far been unable to get my am3517evm to fire up, can you play around with the 3517 to see if there appears to be iva registers that can be read/written to safely? In particular, can the code that idles the iva be run safely on an am3517? Thanks, Mark -- -- 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: v3.10-rc1: backlight brightness after boot on N900
Hi, On Fri, May 17, 2013 at 11:45:35AM -0700, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [130517 11:30]: So I bisected and it points to: commit a2797beadfcb5a0974a30929b613b4d1adb023d1 Author: Jon Hunter jon-hun...@ti.com Date: Thu Apr 4 15:16:15 2013 -0500 gpio/omap: force restore if context loss is not detectable When I revert that commit from 3.10-rc1, the display works again as expected. OK that should be fixed by ab6ec0fb (gpio/omap: ensure gpio context is initialised) in linux-next. Can you check if that helps? Yeah, that fixes it. Thanks, 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
[PATCH 0/6] Drop legacy booting for omap4 for v3.11, boot with device tree only
Hi all, Here are patches against v3.10-rc1 to drop omap4 legacy booting as things are now working well enough for booting omap4 with device tree. We already have am33xx and omap5 booting with device tree only, and converting omap4 is relatively easy with just two board-*.c files merged as we have not accepted any new board-*.c files for quite some time now. By working well enough I mean that I can use my omap4 panda-es with device tree with a Motorola LapDock with HDMI, DVI, HID, USB and WLAN using v3.10-rc1 and the patches in this series plus some extra patches that are driver related. Of course some things will need more work, like PM. But that has not yet been fully working for omap4 anyways, and that work can now be combined with omap5 PM work to some extent. Regards, Tony FYI, the extra patches I'm using in addition to these are: 1. GPIO regression fix (needed at least for SDP nfsroot) ab6ec0fb (gpio/omap: ensure gpio context is initialised) 2. HSMMC DT pbias fix [PATCH] mmc: omap_hsmmc: Fix the DT pbias workaround for MMC controllers 2 to 5 3. WL12XX support patches [PATCH 0/3] WLAN support for omap4 when booted with devicetree 4. USB host support for panda dts changes ARM: dts: omap4-panda: Add USB Host support 5. Fix for LapDock enumeration usb: musb: Fix LapDock enumeration on omap for boot and slow cable insertion --- Tony Lindgren (6): ARM: OMAP2+: Remove board-4430sdp.c ARM: OMAP2+: Remove board-omap4panda.c ARM: OMAP2+: Remove legacy mux data for omap4 ARM: OMAP2+: Remove omap4 pdata from hsmmc.c ARM: OMAP2+: Remove omap4 pdata for USB ARM: OMAP2+: Remove omap4 ocp2scp pdata arch/arm/mach-omap2/Kconfig| 22 arch/arm/mach-omap2/Makefile |3 arch/arm/mach-omap2/board-4430sdp.c| 765 arch/arm/mach-omap2/board-omap4panda.c | 455 - arch/arm/mach-omap2/devices.c | 123 --- arch/arm/mach-omap2/hsmmc.c| 103 -- arch/arm/mach-omap2/mux.h |3 arch/arm/mach-omap2/mux44xx.c | 1356 arch/arm/mach-omap2/mux44xx.h | 298 -- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 21 arch/arm/mach-omap2/usb-host.c | 194 arch/arm/mach-omap2/usb-musb.c |3 drivers/bus/omap-ocp2scp.c | 60 - include/linux/platform_data/omap_ocp2scp.h | 31 - 14 files changed, 10 insertions(+), 3427 deletions(-) delete mode 100644 arch/arm/mach-omap2/board-4430sdp.c delete mode 100644 arch/arm/mach-omap2/board-omap4panda.c delete mode 100644 arch/arm/mach-omap2/mux44xx.c delete mode 100644 arch/arm/mach-omap2/mux44xx.h delete mode 100644 include/linux/platform_data/omap_ocp2scp.h -- Signature -- 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/6] ARM: OMAP2+: Remove board-4430sdp.c
We can now boot with device tree. If you don't want to update u-boot,
you can boot with appended DTB with the following instructions:
1. Make sure you have the appended DTB support in .config
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
2. Build the zImage
$ ARCH=arm CROSS_COMPILE=... make zImage
3. Build the device tree blobs
$ ARCH=arm CROSS_COMPILE=... make dtbs
4. Append the dtb to zImage
$ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.dtb /tmp/appended
5. Use mkimage to produce the appended device tree uImage
$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
-n Linux -d /tmp/appended /tmp/uImage
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig |8
arch/arm/mach-omap2/Makefile|1
arch/arm/mach-omap2/board-4430sdp.c | 765 ---
3 files changed, 774 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-4430sdp.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f49cd51..465edd1 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -378,14 +378,6 @@ config MACH_TI8148EVM
depends on SOC_TI81XX
default y
-config MACH_OMAP_4430SDP
- bool OMAP 4430 SDP board
- default y
- depends on ARCH_OMAP4
- select OMAP_PACKAGE_CBL
- select OMAP_PACKAGE_CBS
- select REGULATOR_FIXED_VOLTAGE if REGULATOR
-
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 55a9d67..875d61d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -251,7 +251,6 @@ obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o
obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o
obj-$(CONFIG_MACH_TOUCHBOOK) += board-omap3touchbook.o
-obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o
obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
deleted file mode 100644
index 56a9a4f..000
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ /dev/null
@@ -1,765 +0,0 @@
-/*
- * Board support file for OMAP4430 SDP.
- *
- * Copyright (C) 2009 Texas Instruments
- *
- * Author: Santosh Shilimkar santosh.shilim...@ti.com
- *
- * Based on mach-omap2/board-3430sdp.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/io.h
-#include linux/gpio.h
-#include linux/usb/otg.h
-#include linux/spi/spi.h
-#include linux/i2c/twl.h
-#include linux/mfd/twl6040.h
-#include linux/gpio_keys.h
-#include linux/regulator/machine.h
-#include linux/regulator/fixed.h
-#include linux/pwm.h
-#include linux/leds.h
-#include linux/leds_pwm.h
-#include linux/pwm_backlight.h
-#include linux/irqchip/arm-gic.h
-#include linux/platform_data/omap4-keypad.h
-#include linux/usb/musb.h
-#include linux/usb/phy.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-#include asm/mach/map.h
-
-#include common.h
-#include omap4-keypad.h
-#include linux/wl12xx.h
-#include linux/platform_data/omap-abe-twl6040.h
-
-#include soc.h
-#include mux.h
-#include mmc.h
-#include hsmmc.h
-#include control.h
-#include common-board-devices.h
-#include dss-common.h
-
-#define ETH_KS8851_IRQ 34
-#define ETH_KS8851_POWER_ON48
-#define ETH_KS8851_QUART 138
-#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
-#define OMAP4_SFH7741_ENABLE_GPIO 188
-
-#define GPIO_WIFI_PMENA54
-#define GPIO_WIFI_IRQ 53
-
-static const int sdp4430_keymap[] = {
- KEY(0, 0, KEY_E),
- KEY(0, 1, KEY_R),
- KEY(0, 2, KEY_T),
- KEY(0, 3, KEY_HOME),
- KEY(0, 4, KEY_F5),
- KEY(0, 5, KEY_UNKNOWN),
- KEY(0, 6, KEY_I),
- KEY(0, 7, KEY_LEFTSHIFT),
-
- KEY(1, 0, KEY_D),
- KEY(1, 1, KEY_F),
- KEY(1, 2, KEY_G),
- KEY(1, 3, KEY_SEND),
- KEY(1, 4, KEY_F6),
- KEY(1, 5, KEY_UNKNOWN),
- KEY(1, 6, KEY_K),
- KEY(1, 7, KEY_ENTER),
-
- KEY(2, 0, KEY_X),
- KEY(2, 1, KEY_C),
- KEY(2, 2, KEY_V),
- KEY(2, 3, KEY_END),
- KEY(2, 4, KEY_F7),
- KEY(2, 5, KEY_UNKNOWN),
- KEY(2, 6, KEY_DOT),
- KEY(2, 7, KEY_CAPSLOCK),
-
- KEY(3, 0, KEY_Z),
- KEY(3, 1, KEY_KPPLUS),
- KEY(3, 2, KEY_B),
- KEY(3, 3, KEY_F1),
- KEY(3, 4, KEY_F8),
- KEY(3, 5, KEY_UNKNOWN),
- KEY(3, 6, KEY_O),
- KEY(3, 7,
[PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
We can now boot with device tree. If you don't want to update u-boot,
you can boot with appended DTB with the following instructions:
1. Make sure you have the appended DTB support in .config
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
2. Build the zImage
$ ARCH=arm CROSS_COMPILE=... make zImage
3. Build the device tree blobs
$ ARCH=arm CROSS_COMPILE=... make dtbs
4. Append the correct panda dtb to zImage
Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb
or omap4-panda-es.dtb.
$ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb
/tmp/appended
5. Use mkimage to produce the appended device tree uImage
$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
-n Linux -d /tmp/appended /tmp/uImage
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig|8 -
arch/arm/mach-omap2/Makefile |1
arch/arm/mach-omap2/board-omap4panda.c | 455
3 files changed, 464 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-omap4panda.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 465edd1..1f941c4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -378,14 +378,6 @@ config MACH_TI8148EVM
depends on SOC_TI81XX
default y
-config MACH_OMAP4_PANDA
- bool OMAP4 Panda Board
- default y
- depends on ARCH_OMAP4
- select OMAP_PACKAGE_CBL
- select OMAP_PACKAGE_CBS
- select REGULATOR_FIXED_VOLTAGE if REGULATOR
-
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 875d61d..2cbf3ef 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -251,7 +251,6 @@ obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o
obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o
obj-$(CONFIG_MACH_TOUCHBOOK) += board-omap3touchbook.o
-obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
deleted file mode 100644
index 1e2c75e..000
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ /dev/null
@@ -1,455 +0,0 @@
-/*
- * Board support file for OMAP4430 based PandaBoard.
- *
- * Copyright (C) 2010 Texas Instruments
- *
- * Author: David Anders x0132...@ti.com
- *
- * Based on mach-omap2/board-4430sdp.c
- *
- * Author: Santosh Shilimkar santosh.shilim...@ti.com
- *
- * Based on mach-omap2/board-3430sdp.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/clk.h
-#include linux/io.h
-#include linux/leds.h
-#include linux/gpio.h
-#include linux/usb/otg.h
-#include linux/i2c/twl.h
-#include linux/mfd/twl6040.h
-#include linux/regulator/machine.h
-#include linux/regulator/fixed.h
-#include linux/ti_wilink_st.h
-#include linux/usb/musb.h
-#include linux/usb/phy.h
-#include linux/usb/nop-usb-xceiv.h
-#include linux/wl12xx.h
-#include linux/irqchip/arm-gic.h
-#include linux/platform_data/omap-abe-twl6040.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-#include asm/mach/map.h
-
-#include common.h
-#include soc.h
-#include mmc.h
-#include hsmmc.h
-#include control.h
-#include mux.h
-#include common-board-devices.h
-#include dss-common.h
-
-#define GPIO_HUB_POWER 1
-#define GPIO_HUB_NRESET62
-#define GPIO_WIFI_PMENA43
-#define GPIO_WIFI_IRQ 53
-
-/* wl127x BT, FM, GPS connectivity chip */
-static struct ti_st_plat_data wilink_platform_data = {
- .nshutdown_gpio = 46,
- .dev_name = /dev/ttyO1,
- .flow_cntrl = 1,
- .baud_rate = 300,
- .chip_enable= NULL,
- .suspend= NULL,
- .resume = NULL,
-};
-
-static struct platform_device wl1271_device = {
- .name = kim,
- .id = -1,
- .dev= {
- .platform_data = wilink_platform_data,
- },
-};
-
-static struct gpio_led gpio_leds[] = {
- {
- .name = pandaboard::status1,
- .default_trigger= heartbeat,
- .gpio = 7,
- },
- {
- .name = pandaboard::status2,
- .default_trigger= mmc0,
- .gpio = 8,
- },
-};
-
-static struct gpio_led_platform_data gpio_led_info = {
- .leds = gpio_leds,
-
[PATCH 5/6] ARM: OMAP2+: Remove omap4 pdata for USB
This is no longer needed as omap4 is now booted
using device tree.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 45 -
arch/arm/mach-omap2/usb-host.c | 194
arch/arm/mach-omap2/usb-musb.c |3 -
3 files changed, 242 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 4269fc1..0fd3834 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,7 +20,6 @@
#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
#include linux/platform_data/omap_ocp2scp.h
-#include linux/usb/omap_control_usb.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -253,49 +252,6 @@ static inline void omap_init_camera(void)
#endif
}
-#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
-static struct omap_control_usb_platform_data omap4_control_usb_pdata = {
- .type = 1,
-};
-
-struct resource omap4_control_usb_res[] = {
- {
- .name = control_dev_conf,
- .start = 0x4a002300,
- .end= 0x4a002303,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = otghs_control,
- .start = 0x4a00233c,
- .end= 0x4a00233f,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap4_control_usb = {
- .name = omap-control-usb,
- .id = -1,
- .dev = {
- .platform_data = omap4_control_usb_pdata,
- },
- .num_resources = 2,
- .resource = omap4_control_usb_res,
-};
-
-static inline void __init omap_init_control_usb(void)
-{
- if (!cpu_is_omap44xx())
- return;
-
- if (platform_device_register(omap4_control_usb))
- pr_err(Error registering omap_control_usb device\n);
-}
-
-#else
-static inline void omap_init_control_usb(void) { }
-#endif /* CONFIG_OMAP_CONTROL_USB */
-
int __init omap4_keyboard_init(struct omap4_keypad_platform_data
*sdp4430_keypad_data, struct omap_board_data *bdata)
{
@@ -651,7 +607,6 @@ static int __init omap2_init_devices(void)
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
- omap_init_control_usb();
omap_init_dmic();
omap_init_mcpdm();
omap_init_mcspi();
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index aa27d7f..544c92b 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -188,125 +188,6 @@ static void __init setup_ehci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
return;
}
-static
-void __init setup_4430ehci_io_mux(const enum usbhs_omap_port_mode *port_mode)
-{
- switch (port_mode[0]) {
- case OMAP_EHCI_PORT_MODE_PHY:
- omap_mux_init_signal(usbb1_ulpiphy_stp,
- OMAP_PIN_OUTPUT);
- omap_mux_init_signal(usbb1_ulpiphy_clk,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpiphy_dir,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpiphy_nxt,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpiphy_dat0,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpiphy_dat1,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpiphy_dat2,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpiphy_dat3,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpiphy_dat4,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpiphy_dat5,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpiphy_dat6,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpiphy_dat7,
- OMAP_PIN_INPUT_PULLDOWN);
- break;
- case OMAP_EHCI_PORT_MODE_TLL:
- omap_mux_init_signal(usbb1_ulpitll_stp,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(usbb1_ulpitll_clk,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpitll_dir,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpitll_nxt,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpitll_dat0,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpitll_dat1,
- OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_signal(usbb1_ulpitll_dat2,
-
[PATCH 6/6] ARM: OMAP2+: Remove omap4 ocp2scp pdata
This is omap4+ only and no longer needed as omap4+ can be booted
using device tree.
Also remove the related pdata handling from the driver and the
now unneeded platform_data/omap_ocp2scp.h.
Cc: Kishon Vijay Abraham I kis...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Olof Johansson o...@lixom.net
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 78
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 21
drivers/bus/omap-ocp2scp.c | 60 --
include/linux/platform_data/omap_ocp2scp.h | 31 ---
4 files changed, 190 deletions(-)
delete mode 100644 include/linux/platform_data/omap_ocp2scp.h
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 0fd3834..3f2c85a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -19,7 +19,6 @@
#include linux/of.h
#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
-#include linux/platform_data/omap_ocp2scp.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -513,82 +512,6 @@ static void omap_init_vout(void)
static inline void omap_init_vout(void) {}
#endif
-#if defined(CONFIG_OMAP_OCP2SCP) || defined(CONFIG_OMAP_OCP2SCP_MODULE)
-static int count_ocp2scp_devices(struct omap_ocp2scp_dev *ocp2scp_dev)
-{
- int cnt = 0;
-
- while (ocp2scp_dev-drv_name != NULL) {
- cnt++;
- ocp2scp_dev++;
- }
-
- return cnt;
-}
-
-static void __init omap_init_ocp2scp(void)
-{
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- int bus_id = -1, dev_cnt = 0, i;
- struct omap_ocp2scp_dev *ocp2scp_dev;
- const char *oh_name, *name;
- struct omap_ocp2scp_platform_data *pdata;
-
- if (!cpu_is_omap44xx())
- return;
-
- oh_name = ocp2scp_usb_phy;
- name= omap-ocp2scp;
-
- oh = omap_hwmod_lookup(oh_name);
- if (!oh) {
- pr_err(%s: could not find omap_hwmod for %s\n, __func__,
- oh_name);
- return;
- }
-
- pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
- if (!pdata) {
- pr_err(%s: No memory for ocp2scp pdata\n, __func__);
- return;
- }
-
- ocp2scp_dev = oh-dev_attr;
- dev_cnt = count_ocp2scp_devices(ocp2scp_dev);
-
- if (!dev_cnt) {
- pr_err(%s: No devices connected to ocp2scp\n, __func__);
- kfree(pdata);
- return;
- }
-
- pdata-devices = kzalloc(sizeof(struct omap_ocp2scp_dev *)
- * dev_cnt, GFP_KERNEL);
- if (!pdata-devices) {
- pr_err(%s: No memory for ocp2scp pdata devices\n, __func__);
- kfree(pdata);
- return;
- }
-
- for (i = 0; i dev_cnt; i++, ocp2scp_dev++)
- pdata-devices[i] = ocp2scp_dev;
-
- pdata-dev_cnt = dev_cnt;
-
- pdev = omap_device_build(name, bus_id, oh, pdata, sizeof(*pdata));
- if (IS_ERR(pdev)) {
- pr_err(Could not build omap_device for %s %s\n,
- name, oh_name);
- kfree(pdata-devices);
- kfree(pdata);
- return;
- }
-}
-#else
-static inline void omap_init_ocp2scp(void) { }
-#endif
-
/*-*/
static int __init omap2_init_devices(void)
@@ -616,7 +539,6 @@ static int __init omap2_init_devices(void)
omap_init_sti();
omap_init_rng();
omap_init_vout();
- omap_init_ocp2scp();
return 0;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index eaba9dc..8b60678 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -21,7 +21,6 @@
#include linux/io.h
#include linux/platform_data/gpio-omap.h
#include linux/power/smartreflex.h
-#include linux/platform_data/omap_ocp2scp.h
#include linux/i2c-omap.h
#include linux/omap-dma.h
@@ -2695,25 +2694,6 @@ static struct omap_hwmod_class
omap44xx_ocp2scp_hwmod_class = {
.sysc = omap44xx_ocp2scp_sysc,
};
-/* ocp2scp dev_attr */
-static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
- {
- .name = usb_phy,
- .start = 0x4a0ad080,
- .end= 0x4a0ae000,
- .flags = IORESOURCE_MEM,
- },
- { }
-};
-
-static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
- {
- .drv_name = omap-usb2,
- .res= omap44xx_usb_phy_and_pll_addrs,
- },
- { }
-};
-
/* ocp2scp_usb_phy */
static struct
[PATCH 4/6] ARM: OMAP2+: Remove omap4 pdata from hsmmc.c
This is no longer needed as omap4 is now booted using
device tree.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/hsmmc.c | 103 ---
1 file changed, 10 insertions(+), 93 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 2ef1f87..07d4c7b 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -29,7 +29,6 @@
static u16 control_pbias_offset;
static u16 control_devconf1_offset;
-static u16 control_mmc1;
#define HSMMC_NAME_LEN 9
@@ -121,57 +120,6 @@ static void omap_hsmmc1_after_set_reg(struct device *dev,
int slot,
}
}
-static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
- int power_on, int vdd)
-{
- u32 reg;
-
- /*
-* Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
-* card with Vcc regulator (from twl4030 or whatever). OMAP has both
-* 1.8V and 3.0V modes, controlled by the PBIAS register.
-*/
- reg = omap4_ctrl_pad_readl(control_pbias_offset);
- reg = ~(OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
- OMAP4_MMC1_PWRDNZ_MASK |
- OMAP4_MMC1_PBIASLITE_VMODE_MASK);
- omap4_ctrl_pad_writel(reg, control_pbias_offset);
-}
-
-static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
-int power_on, int vdd)
-{
- u32 reg;
- unsigned long timeout;
-
- if (power_on) {
- reg = omap4_ctrl_pad_readl(control_pbias_offset);
- reg |= OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK;
- if ((1 vdd) = MMC_VDD_165_195)
- reg = ~OMAP4_MMC1_PBIASLITE_VMODE_MASK;
- else
- reg |= OMAP4_MMC1_PBIASLITE_VMODE_MASK;
- reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
- OMAP4_MMC1_PWRDNZ_MASK);
- omap4_ctrl_pad_writel(reg, control_pbias_offset);
-
- timeout = jiffies + msecs_to_jiffies(5);
- do {
- reg = omap4_ctrl_pad_readl(control_pbias_offset);
- if (!(reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK))
- break;
- usleep_range(100, 200);
- } while (!time_after(jiffies, timeout));
-
- if (reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK) {
- pr_err(Pbias Voltage is not same as LDO\n);
- /* Caution : On VMODE_ERROR Power Down MMC IO */
- reg = ~(OMAP4_MMC1_PWRDNZ_MASK);
- omap4_ctrl_pad_writel(reg, control_pbias_offset);
- }
- }
-}
-
static void hsmmc2_select_input_clk_src(struct omap_mmc_platform_data *mmc)
{
u32 reg;
@@ -317,11 +265,7 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
mmc-slots[0].pm_caps = c-pm_caps;
mmc-slots[0].internal_clock = !c-ext_clock;
mmc-max_freq = c-max_freq;
- if (cpu_is_omap44xx())
- mmc-reg_offset = OMAP4_MMC_REG_OFFSET;
- else
- mmc-reg_offset = 0;
-
+ mmc-reg_offset = 0;
mmc-get_context_loss_count = hsmmc_get_context_loss;
mmc-slots[0].switch_pin = c-gpio_cd;
@@ -368,24 +312,14 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
if (!soc_is_am35xx())
mmc-slots[0].features |= HSMMC_HAS_PBIAS;
- if (cpu_is_omap44xx() (omap_rev() OMAP4430_REV_ES1_0))
- mmc-slots[0].features |= HSMMC_HAS_UPDATED_RESET;
-
switch (c-mmc) {
case 1:
if (mmc-slots[0].features HSMMC_HAS_PBIAS) {
/* on-chip level shifting via PBIAS0/PBIAS1 */
- if (cpu_is_omap44xx()) {
- mmc-slots[0].before_set_reg =
- omap4_hsmmc1_before_set_reg;
- mmc-slots[0].after_set_reg =
- omap4_hsmmc1_after_set_reg;
- } else {
- mmc-slots[0].before_set_reg =
- omap_hsmmc1_before_set_reg;
- mmc-slots[0].after_set_reg =
- omap_hsmmc1_after_set_reg;
- }
+ mmc-slots[0].before_set_reg =
+ omap_hsmmc1_before_set_reg;
+ mmc-slots[0].after_set_reg =
+ omap_hsmmc1_after_set_reg;
}
if (soc_is_am35xx())
@@ -563,34 +497,17 @@ free_mmc:
void __init omap_hsmmc_init(struct omap2_hsmmc_info *controllers)
{
- u32 reg;
-
if (omap_hsmmc_done)
return;
[GIT PULL] omap fixes for v3.10-rc1
The following changes since commit f722406faae2d073cc1d01063d1123c35425939e: Linux 3.10-rc1 (2013-05-11 17:14:08 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10-rc1/fixes for you to fetch changes up to a6d25f4c951b8b28f2eaec6f891ff834622532f2: ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock (2013-05-17 10:07:45 -0700) Fixes for omaps: - a section mismatch fix for hwmod - boot fix for omap2plus_defconfig for omap2 - musb interrupt fix when using device tree - am33xx clock fix that I missed earlier somehow - omap1 dma return code error fix Paul Walmsley (1): ARM: OMAP2+: Add missing CONFIG_ARCH_MULTI_V6=y to omap2plus_defconfig Tony Lindgren (1): ARM: dts: Fix musb interrupt for device tree booting Vaibhav Hiremath (1): ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock Wei Yongjun (1): ARM: OMAP: fix error return code in omap1_system_dma_init() jean-philippe francois (1): ARM: OMAP: fix __init section mismatch for _enable_preprogram arch/arm/boot/dts/omap3.dtsi | 2 +- arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/mach-omap1/dma.c | 1 + arch/arm/mach-omap2/cclock33xx_data.c | 26 +++--- arch/arm/mach-omap2/omap_hwmod.c | 2 +- 5 files changed, 27 insertions(+), 5 deletions(-) -- 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 6/6] ARM: OMAP2+: Remove omap4 ocp2scp pdata
On Fri, May 17, 2013 at 12:18:03PM -0700, Tony Lindgren wrote: This is omap4+ only and no longer needed as omap4+ can be booted using device tree. Also remove the related pdata handling from the driver and the now unneeded platform_data/omap_ocp2scp.h. Cc: Kishon Vijay Abraham I kis...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Arnd Bergmann a...@arndb.de Cc: Olof Johansson o...@lixom.net Signed-off-by: Tony Lindgren t...@atomide.com fine by me :-) Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
[PATCH] ARM: OMAP2+: Fix multiple randconfig errors if no SoC is selected, take3
If no SoC is selected, we should not build any of the SoC support code for omap2+. Otherwise we can get multiple errors with make randconfig. Based on the mailing list discussions we came to the conclusion that this is best fixed with a combination of Makefile and Kconfig changes. Some issues are best fixed by selecting objects in Makefile based on a combination of features and SoC as suggested by Arnd Bergman and done in commit 572b16db7 (ARM: OMAP: build SMP code only for OMAP4/5). For the SoC related code, we should not build any of the dependant features though. This is best done by making the SoC dependant features depend on at least one SoC being selected as done in this patch. The minimal fix is to select the existing config ARCH_OMAP only if a SoC is selected, and then build the SoC dependant objects only if config ARCH_OMAP is selected. While at it, we can also change ARCH_OMAP2 to a menuconfig which allows us to drop the now unnecessary menu entry. For reference, the build errors without this patch are something like: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_deassert_hardreset': arch/arm/mach-omap2/omap_hwmod.c:1677: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:1678: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:1705: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/omap_hwmod.c:1708: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2172: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `pm_dbg_show_timers': arch/arm/mach-omap2/pm-debug.c:155: undefined reference to `pwrdm_for_each' arch/arm/mach-omap2/built-in.o: In function `pwrdm_dbg_show_timer': arch/arm/mach-omap2/pm-debug.c:132: undefined reference to `pwrdm_state_switch' arch/arm/mach-omap2/built-in.o: In function `pm_dbg_show_counters': arch/arm/mach-omap2/pm-debug.c:147: undefined reference to `pwrdm_for_each' arch/arm/mach-omap2/pm-debug.c:148: undefined reference to `clkdm_for_each' arch/arm/mach-omap2/built-in.o: In function `pwrdm_dbg_show_counter': arch/arm/mach-omap2/pm-debug.c:102: undefined reference to `pwrdm_read_pwrst' arch/arm/mach-omap2/pm-debug.c:103: undefined reference to `pwrdm_read_pwrst' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' arch/arm/mach-omap2/built-in.o: In function `pm_dbg_init': arch/arm/mach-omap2/pm-debug.c:272: undefined reference to `pwrdm_for_each' Cc: Arnd Bergmann a...@arndb.de Cc: Rob Herring rob.herr...@calxeda.com Cc: Russell King - ARM Linux li...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- Here's a combined Kconfig + Makefile fix for this. I've tried to keep it as minimal as possible as I'd like to get this fix merged as a fix. That is unless you guys think it's too intrusive for the -rc series. diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..b6eb91d 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -1,11 +1,10 @@ config ARCH_OMAP bool -config ARCH_OMAP2PLUS +menuconfig ARCH_OMAP2PLUS bool TI OMAP2/3/4/5 SoCs with device tree support if (ARCH_MULTI_V6 || ARCH_MULTI_V7) select ARCH_HAS_CPUFREQ select ARCH_HAS_HOLES_MEMORYMODEL - select ARCH_OMAP select ARCH_REQUIRE_GPIOLIB select CLKDEV_LOOKUP select
Re: [PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations
On Mon, May 13, 2013 at 10:07:47PM -0500, Joel A Fernandes wrote: Calling runtime PM API for every block causes serious perf hit to crypto operations that are done on a long buffer. As crypto is performed on a page boundary, encrypting large buffers can cause a series of crypto operations divided by page. The runtime PM API is also called those many times. We call runtime_pm_get_sync only at beginning on the session (cra_init) and runtime_pm_put at the end. This result in upto a 50% speedup as below. This doesn't make the driver to keep the system awake as runtime get/put is only called during a crypto session which completes usually quickly. Before: root@beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s After: root@beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s While at it, also drop enter and exit pr_debugs, in related code. tracers can be used for that. Tested on a Beaglebone (AM335x SoC) board. Signed-off-by: Joel A Fernandes joelag...@ti.com --- FWIW, Acked-by: Mark A. Greer mgr...@animalcreek.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] ARM: OMAP3: Fix iva2_pwrdm settings for 3703
On Fri, May 17, 2013 at 8:56 PM, Mark A. Greer mgr...@animalcreek.com wrote: On Thu, May 16, 2013 at 12:19:20PM +0200, Yegor Yefremov wrote: On 15.05.2013 23:50, Mark A. Greer wrote: On Wed, May 15, 2013 at 10:07:35AM -0700, Tony Lindgren wrote: Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with? I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days). I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out. I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903 I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html I have such a system running, so if you have any other patches/ideas to test, I would do it. Yegor, since I've so far been unable to get my am3517evm to fire up, can you play around with the 3517 to see if there appears to be iva registers that can be read/written to safely? In particular, can the code that idles the iva be run safely on an am3517? I'll look into this next week. am3517 and IVA seems to be a really big mystery. In the TI forum will be stated, there is no IVA: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/150961.aspx, but TRM has various appearances of IVA2 registers, but no real description/explanation of what is IVA and how to eat it. 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: v3.10-rc1: backlight brightness after boot on N900
On Fri, May 17, 2013 at 8:45 PM, Tony Lindgren t...@atomide.com wrote: OK that should be fixed by ab6ec0fb (gpio/omap: ensure gpio context is initialised) in linux-next. Can you check if that helps? Looks like it has not yet been merged to mainline tree. Linus W, any news on when you might be sending that fix upstream? It fell out because of the other debacle during the merge window. I'm more than overloaded (due to the ever increasing development pace of the kernel I guess) so queueing fixes takes some time. 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: v3.10-rc1: backlight brightness after boot on N900
* Linus Walleij linus.wall...@linaro.org [130517 14:56]: On Fri, May 17, 2013 at 8:45 PM, Tony Lindgren t...@atomide.com wrote: OK that should be fixed by ab6ec0fb (gpio/omap: ensure gpio context is initialised) in linux-next. Can you check if that helps? Looks like it has not yet been merged to mainline tree. Linus W, any news on when you might be sending that fix upstream? It fell out because of the other debacle during the merge window. I'm more than overloaded (due to the ever increasing development pace of the kernel I guess) so queueing fixes takes some time. Yes I can totally understand that, thanks for the update! 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
