2.6.37-omap1 tag?
Hi, Are there any plans to do a 2.6.37-omap1 tag? regards, Koen -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.37-omap1 tag?
Koen Kooi wrote: Are there any plans to do a 2.6.37-omap1 tag? Given that linux-omap is now closely tracking mainline, is this still needed? - Anand -- To unsubscribe from this list: send the line unsubscribe 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] TWD: enable one-shot mode
On Mon, Jan 10, 2011 at 09:12:36PM -0800, Stephen Boyd wrote: On 12/24/2010 11:18 AM, Russell King - ARM Linux wrote: Allow one shot timer mode to be used with the TWD. This allows NOHZ mode to be used on SMP systems using the TWD localtimer. Tested on Versatile Express. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- Acks/Tested-by's would be appreciated, thanks. I see this patch was already tested and merged but can you elaborate on why this was done? From what I understand, NOHZ selects one-shot (like is done in this patch), so why don't the machines with a TWD choose NOHZ or high res timers? You're right - so it's not actually required. It should probably be reverted, though it does no damage... -- To unsubscribe from this list: send the line unsubscribe 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/5] OMAP: clockdomain: Arch specific funcs to handle deps
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, January 11, 2011 7:02 AM To: Rajendra Nayak Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com; b-cous...@ti.com Subject: Re: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to handle deps On Wed, 5 Jan 2011, Rajendra Nayak wrote: Define the following architecture specific funtions for omap2/3 .clkdm_add_wkdep .clkdm_del_wkdep .clkdm_read_wkdep .clkdm_clear_all_wkdeps .clkdm_add_sleepdep .clkdm_del_sleepdep .clkdm_read_sleepdep .clkdm_clear_all_sleepdeps Convert the platform-independent framework to call these functions. With this also move the clkdm lookups for all wkdep_srcs and sleepdep_srcs at clkdm_init. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/clockdomain.c| 80 ++- arch/arm/mach-omap2/clockdomain.h|2 + arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 113 ++ arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |2 +- This is definitely a good start, but a lot of OMAP4 stuff still needs to be done. For example, OMAP4 has static wakeup dependencies just like OMAP2/3; described in section 3.1.1.1.7.3 Wake-Up Dependency of the OMAP4430 TRM Rev. L. OMAP4 also has static sleep dependencies just like OMAP3; described in section 3.1.1.1.7.1 Static Dependency of the OMAP4430 TRM Rev. L. I already have some patches to support static dependencies for OMAP4. Still working towards getting the autogen scripts in place, they seem to be a bit out of sync with whats in mainline today for clockdomains. I can post early patches as RFC to get your views on it. The only difference wrt OMAP3 is there is no control on OMAP4 to set/clear sleep and wakeup dependencies separately and hence they are called Static dependency and not 'Static wakeup' or 'Static sleep'. Setting a static dependency between clock domains on OMAP4 means setting sleep *as well as* wakeup dependency. The dynamic wakeup dependencies (section 3.1.1.1.7.2 of the TRM) and the hardware inactivity timer are new for OMAP4. What's the plan to add support for these? I will be working on supporting these as well. Can be supported easily on top of the clockdomain split series. Still need to get the autogen scripts updated to generate the dynamic dependency data. Based on a brief look, it would seem to make sense to add support now for static sleep dependencies. These seem quite similar to the OMAP3 implementation, in that they are between clockdomains. Again like I said above, my next patch series will add support for static (sleep and wakeup) dependencies. The other 'wakeup dependency' that the TRM section 3.1.1.1.7.3 talks about is slightly different. See my comments below. Dynamic wakeup dependencies and the prescaler timer configuration should be fairly easy to add since it is a new feature, and thus no OMAP2/3 implementation is needed. The dyndep stuff is between clockdomains, so there shouldn't be any interaction needed with the hwmod code by my reading. Static wakeup dependency support appears a little more tricky, since the dependencies are between modules and clockdomains on OMAP4, rather than between clockdomains and clockdomains as they were on OMAP2/3. One way to handle this would be to change the existing wkdep interface for all OMAPs to be between modules and clockdomains; then for the OMAP2/3 implementations, use the hwmod code/data to get the clockdomain of the module's main_clk. Another is to add a separate interface to add wkdeps between a module and clockdomain, use that for OMAP4, but use the existing clockdomain-to-clockdomain interface for OMAP2/3. It might be necessary to do both until the hwmod data is more complete, then perhaps phase out the latter interface. Thoughts? The wakeup dependency here (between a module and a clock domain) is very different from the static dependency (between clock domains) and is very much like what the PM_processor_GRPSEL registers handled in OMAP3. They are used to control which processor is woken up on a given module/ peripheral wakeup event. I have not given much thought on this for now but looks like this needs to be handled in some way using hwmod itself. I need to work some more to see how this can be handled. Regards, Rajendra - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to handle deps
Hi Paul,
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Tuesday, January 11, 2011 6:36 AM
To: Rajendra Nayak
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com;
b-cous...@ti.com
Subject: Re: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to
handle deps
Hi Rajendra
On Wed, 5 Jan 2011, Rajendra Nayak wrote:
Define the following architecture specific funtions for omap2/3
.clkdm_add_wkdep
.clkdm_del_wkdep
.clkdm_read_wkdep
.clkdm_clear_all_wkdeps
.clkdm_add_sleepdep
.clkdm_del_sleepdep
.clkdm_read_sleepdep
.clkdm_clear_all_sleepdeps
Convert the platform-independent framework to call these functions.
With this also move the clkdm lookups for all wkdep_srcs and
sleepdep_srcs at clkdm_init.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/clockdomain.c| 80
++-
arch/arm/mach-omap2/clockdomain.h|2 +
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 113
++
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |2 +-
5 files changed, 150 insertions(+), 49 deletions(-)
create mode 100644 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
diff --git a/arch/arm/mach-omap2/Makefile
b/arch/arm/mach-omap2/Makefile
index 4ab82f6..d28db0a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -102,8 +102,10 @@ obj-$(CONFIG_ARCH_OMAP4) +=
$(powerdomain-common) \
# PRCM clockdomain control
obj-$(CONFIG_ARCH_OMAP2) += clockdomain.o \
+ clockdomain2xxx_3xxx.o \
clockdomains2xxx_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP3) += clockdomain.o \
+ clockdomain2xxx_3xxx.o \
clockdomains2xxx_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += clockdomain.o \
clockdomains44xx_data.o
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 3e40184..c32480c 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -308,6 +308,7 @@ void clkdm_init(struct clockdomain **clkdms,
struct clockdomain **c = NULL;
struct clockdomain *clkdm;
struct clkdm_autodep *autodep = NULL;
+ struct clkdm_dep *cd;
if (!custom_funcs)
WARN(1, No custom clkdm functions registered\n);
@@ -333,7 +334,18 @@ void clkdm_init(struct clockdomain **clkdms,
else if (clkdm-flags CLKDM_CAN_DISABLE_AUTO)
omap2_clkdm_deny_idle(clkdm);
+ for (cd = clkdm-wkdep_srcs; cd cd-clkdm_name; cd++) {
+ if (!omap_chip_is(cd-omap_chip))
+ continue;
+ cd-clkdm = _clkdm_lookup(cd-clkdm_name);
+ }
clkdm_clear_all_wkdeps(clkdm);
+
+ for (cd = clkdm-sleepdep_srcs; cd cd-clkdm_name;
cd++) {
+ if (!omap_chip_is(cd-omap_chip))
+ continue;
+ cd-clkdm = _clkdm_lookup(cd-clkdm_name);
+ }
clkdm_clear_all_sleepdeps(clkdm);
}
}
@@ -445,8 +457,8 @@ int clkdm_add_wkdep(struct clockdomain *clkdm1,
struct clockdomain *clkdm2)
pr_debug(clockdomain: hardware will wake up %s when %s
wakes
up\n, clkdm1-name, clkdm2-name);
- omap2_prm_set_mod_reg_bits((1 clkdm2-dep_bit),
-clkdm1-pwrdm.ptr-prcm_offs,
PM_WKDEP);
+ if (arch_clkdm arch_clkdm-clkdm_add_wkdep)
+ arch_clkdm-clkdm_add_wkdep(clkdm1, clkdm2);
Putting this test inside the loop doesn't make sense to me; arch_clkdm
and
arch_clkdm-clkdm_* only need to be tested once outside the loop.
Please
do somtehing like this instead:
Sure, will do the changes.
cd = _clkdm_deps_lookup(clkdm2, clkdm1-wkdep_srcs);
if (IS_ERR(cd))
ret = PTR_ERR(cd);
if (!arch_clkdm || !arch_clkdm-clkdm_add_wkdep)
ret = -EINVAL;
if (ret) {
pr_debug(clockdomain: hardware cannot set/clear wake up
of
%s when %s wakes up\n, clkdm1-name,
clkdm2-name);
return ret;
}
if (atomic_inc_return(cd-wkdep_usecount) == 1) {
pr_debug(clockdomain: hardware will wake up %s when %s
wakes
up\n, clkdm1-name, clkdm2-name);
arch_clkdm-clkdm_add_wkdep(clkdm1, clkdm2);
}
As in the above code, we should probably return an error if the function
pointers don't exist. That should allow us to get rid of the
if (!cpu_is_omap34xx())
return -EINVAL;
tests in the sleepdep functions, since
Re: [PATCH 7/7 v2] OMAP: runtime: McSPI driver runtime conversion
On Sat, Jan 8, 2011 at 4:19 AM, Kevin Hilman khil...@ti.com wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Wed, Dec 01, 2010 at 07:32:11PM +0530, Govindraj.R wrote:
McSPI runtime conversion.
Changes involves:
1) remove clock framework apis to use runtime framework apis.
2) context restore from runtime resume which is a callback for get_sync.
3) Remove SYSCONFIG(sysc) register handling
(a) Remove context save and restore of sysc reg and remove soft
reset
done from sysc reg as this will be done with hwmod framework.
(b) Also cleanup sysc reg bit macros.
4) Rename the omap2_mcspi_reset function to omap2_mcspi_master_setup
function as with hwmod changes soft reset will be done in
hwmod framework itself and use the return value from clock
enable function to return for failure scenarios.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Reviewed-by: Partha Basak p-bas...@ti.com
One comment below, but otherwise looks good to me. Since the majority
of the changes are in arch/arm, feel free to add my Acked-by for the
whole series and merge via the omap tree.
Thanks, we'll merge this through the OMAP tree.
None of my comments are showstoppers, so I'm even fine with merging
them as-is as long as followup patches are posted to address the
comments.
Govindraj, since we've missed 2.6.38 for this series, I'd like to see the
last few
minor issues cleaned up before merge, especially the various casting and
CodingStyle issues that Grant found.
Yes sure will post out v3 in a weeks time. Fixing comments and
adding ack from Grant.
--
Thanks,
Govindraj.R
Kevin
In particular, I'd really like to see the data duplication issue from
the first 4 patches addressed.
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/spi/omap2_mcspi.c | 120
+---
1 files changed, 46 insertions(+), 74 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index ad3811e..a1b157f 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -33,6 +33,7 @@
#include linux/clk.h
#include linux/io.h
#include linux/slab.h
+#include linux/pm_runtime.h
#include linux/spi/spi.h
@@ -46,7 +47,6 @@
#define OMAP2_MCSPI_MAX_CTRL 4
#define OMAP2_MCSPI_REVISION 0x00
-#define OMAP2_MCSPI_SYSCONFIG 0x10
#define OMAP2_MCSPI_SYSSTATUS 0x14
#define OMAP2_MCSPI_IRQSTATUS 0x18
#define OMAP2_MCSPI_IRQENABLE 0x1c
@@ -63,13 +63,6 @@
/* per-register bitmasks: */
-#define OMAP2_MCSPI_SYSCONFIG_SMARTIDLE BIT(4)
-#define OMAP2_MCSPI_SYSCONFIG_ENAWAKEUP BIT(2)
-#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE BIT(0)
-#define OMAP2_MCSPI_SYSCONFIG_SOFTRESET BIT(1)
-
-#define OMAP2_MCSPI_SYSSTATUS_RESETDONE BIT(0)
-
#define OMAP2_MCSPI_MODULCTRL_SINGLE BIT(0)
#define OMAP2_MCSPI_MODULCTRL_MS BIT(2)
#define OMAP2_MCSPI_MODULCTRL_STEST BIT(3)
@@ -122,13 +115,12 @@ struct omap2_mcspi {
spinlock_t lock;
struct list_head msg_queue;
struct spi_master *master;
- struct clk *ick;
- struct clk *fck;
/* Virtual base address of the controller */
void __iomem *base;
unsigned long phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma *dma_channels;
+ struct device *dev;
Inconsistent indentation with the rest of the structure (tabs vs. spaces).
};
struct omap2_mcspi_cs {
@@ -144,7 +136,6 @@ struct omap2_mcspi_cs {
* corresponding registers are modified.
*/
struct omap2_mcspi_regs {
- u32 sysconfig;
u32 modulctrl;
u32 wakeupenable;
struct list_head cs;
@@ -268,9 +259,6 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi
*mcspi)
mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
omap2_mcspi_ctx[spi_cntrl-bus_num - 1].modulctrl);
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
- omap2_mcspi_ctx[spi_cntrl-bus_num - 1].sysconfig);
-
mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
omap2_mcspi_ctx[spi_cntrl-bus_num - 1].wakeupenable);
@@ -280,20 +268,12 @@ static void omap2_mcspi_restore_ctx(struct
omap2_mcspi *mcspi)
}
static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
{
- clk_disable(mcspi-ick);
- clk_disable(mcspi-fck);
+ pm_runtime_put_sync(mcspi-dev);
}
static int omap2_mcspi_enable_clocks(struct omap2_mcspi *mcspi)
{
- if (clk_enable(mcspi-ick))
- return -ENODEV;
- if (clk_enable(mcspi-fck))
- return -ENODEV;
-
- omap2_mcspi_restore_ctx(mcspi);
-
- return 0;
+ return pm_runtime_get_sync(mcspi-dev);
}
static int
[PATCH] omap3: igep3: Add omap_reserve functionality
This patch adds omap_reserve functionality to board-igep0030.c. This patch is in similar lines to commit id 71ee7dad9b6991, from Russell king Cc: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com --- arch/arm/mach-omap2/board-igep0030.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-igep0030.c b/arch/arm/mach-omap2/board-igep0030.c index 11b944f..4dc62a9 100644 --- a/arch/arm/mach-omap2/board-igep0030.c +++ b/arch/arm/mach-omap2/board-igep0030.c @@ -450,6 +450,7 @@ static void __init igep3_init(void) MACHINE_START(IGEP0030, IGEP OMAP3 module) .boot_params= 0x8100, + .reserve= omap_reserve, .map_io = omap3_map_io, .init_irq = igep3_init_irq, .init_machine = igep3_init, -- 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
[PATCH v5 2/3] omap3: beaglexm: fix DVI reset GPIO
From: Koen Kooi k...@beagleboard.org
GPIO reset line for Beagle XM is different from vanilla beagle
so we populate it as part of gpio update routine.
This in part fixes the issue of display not functioning on beagle XM
platform.
[...@ti.com: split up, added descriptive changelogs]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Koen Kooi k...@beagleboard.org
---
arch/arm/mach-omap2/board-omap3beagle.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index af1166b..673deb9 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -199,7 +199,7 @@ static struct omap_dss_device beagle_dvi_device = {
.name = dvi,
.driver_name = generic_panel,
.phy.dpi.data_lines = 24,
- .reset_gpio = 170,
+ .reset_gpio = -EINVAL,
.platform_enable = beagle_enable_dvi,
.platform_disable = beagle_disable_dvi,
};
@@ -307,6 +307,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
else
gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ /* DVI reset GPIO is different between beagle revisions */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ beagle_dvi_device.reset_gpio = 129;
+ else
+ beagle_dvi_device.reset_gpio = 170;
+
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/3] OMAP3: beaglexm: GPIO fixes
Hi, revision 5 of this series. As discussed in the threads: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/ http://marc.info/?t=12154003084r=1w=2 here is the split up series with commit message after discussion: http://www.beagleboard.org/irclogs/index.php?date=2011-01-06#T19:12:21 Koen Kooi (3): omap3: beaglexm: fix EHCI power up GPIO dir omap3: beaglexm: fix DVI reset GPIO omap3: beaglexm: fix power on of DVI arch/arm/mach-omap2/board-omap3beagle.c | 38 ++- 1 files changed, 32 insertions(+), 6 deletions(-) v5: review comment incorporation - gpio_direction_output removable. v4: http://marc.info/?t=12944413011r=1w=2 no functional change. minor cleanups in commit logs incorporating offline feedback v3: http://marc.info/?t=12943438476r=1w=2 split up the series, addressed review comments v2: http://marc.info/?t=12927697792r=1w=2 Reenable the PMU stat LED v1: http://marc.info/?t=12917257101r=1w=2 Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/3] omap3: beaglexm: fix EHCI power up GPIO dir
From: Koen Kooi k...@beagleboard.org EHCI enable power pin is inverted (active high) in comparison to vanilla beagle which is active low. Handle this case conditionally. Without this fix, Beagle XM 4 port EHCI will not function and no networking will be available [...@ti.com: split up, added descriptive changelogs] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Koen Kooi k...@beagleboard.org --- arch/arm/mach-omap2/board-omap3beagle.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 6c12760..af1166b 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -297,9 +297,15 @@ static int beagle_twl_gpio_setup(struct device *dev, gpio_request(gpio + 1, EHCI_nOC); gpio_direction_input(gpio + 1); - /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */ + /* +* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active +* high / others active low) +*/ gpio_request(gpio + TWL4030_GPIO_MAX, nEN_USB_PWR); - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); + else + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */ gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1; -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP DSS Enable clocks in dss_setup_partial_planes
From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00 2001 From: Ben Tucker btuc...@mpc-data.co.uk Date: Thu, 13 Jan 2011 12:56:45 + Subject: [PATCH] OMAP DSS Enable clocks in dss_setup_partial_planes Enable the interface clocks while calling configure_dispc(). --- drivers/video/omap2/dss/manager.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c index 545e9b9..cb90dac 100644 --- a/drivers/video/omap2/dss/manager.c +++ b/drivers/video/omap2/dss/manager.c @@ -1106,7 +1106,9 @@ void dss_setup_partial_planes(struct omap_dss_device *dssdev, mc-w = w; mc-h = h; + dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1); configure_dispc(); + dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1); mc-do_manual_update = false; -- 1.7.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Spinlock recursion after root nfs mount
Hi all,
Has anyone been trying to boot w/k.org lately?
I tried with:
- commit e0e736fc + 2 patches attached I got from patchworks
- 4430SDP w/ES2.1
- Busybox FS through NFS.
I see the attached log, which shows a spinlock recursion bug.
I did a git bisect, and found this offending commit:
34286d6662308d82aed891852d04c7c3a2649b16 is the first bad commit
commit 34286d6662308d82aed891852d04c7c3a2649b16
Author: Nick Piggin npig...@kernel.dk
Date: Fri Jan 7 17:49:57 2011 +1100
fs: rcu-walk aware d_revalidate method
Require filesystems be aware of .d_revalidate being called in rcu-walk
mode (nd-flags LOOKUP_RCU). For now do a simple push down, returning
-ECHILD from all implementations.
Signed-off-by: Nick Piggin npig...@kernel.dk
:04 04 409693ac5c32f4daa0c9be786e85b04dea32a24f
1813b382a41b72ccb5d810c282639961e6d81b73 M Documentation
:04 04 a51e00e2f5335f8804e9e5fab10a26b0d67ac302
333fc859d8d1f2badea9023072e1ab356f042215 M drivers
:04 04 53158279a9808c50157dd4b6ec5c35951b3a60af
301c546b257a5b4f3f09289fc5e8f55e66b2b6b9 M fs
:04 04 e68ac1512333db998dc539a40a2b43dcee9cb074
f238839ffc4021e276be9d39d4e9c510575c9f44 M include
And I narrowed it down to this line:
In file fs/namei.c:
...
...
static int nameidata_dentry_drop_rcu(struct nameidata *nd, struct dentry
*dentry)
{
struct fs_struct *fs = current-fs;
struct dentry *parent = nd-path.dentry;
BUG_ON(!(nd-flags LOOKUP_RCU));
if (nd-root.mnt) {
spin_lock(fs-lock);
if (nd-root.mnt != fs-root.mnt ||
nd-root.dentry != fs-root.dentry)
goto err_root;
}
spin_lock(parent-d_lock);
spin_lock_nested(dentry-d_lock, DENTRY_D_LOCK_NESTED); -- HERE THE
RECURSION IS FIRED UP
...
...
I had been googling around and I just saw Uwe Santosh reporting the problem
in LKML, but nobody has answered.
Has anyone seen this aswell in other platforms? (OMAP3 based boards)
Regards,
Sergio
## Booting image at 8030 ...
Image Name: Linux-2.6.37-03740-gbc4a241
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:2941368 Bytes = 2.8 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[0.00] Linux version 2.6.37-03740-gbc4a241
(x0091...@dtx0091359-ubuntu-1) (gcc version 4.4.1 (Sourcery G++ Lite
2010q1-202) ) #3 SMP Mon Jan 10 15:09:12 CST 2011
[0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f
[0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
[0.00] Machine: OMAP4430 4430SDP board
[0.00] Memory policy: ECC disabled, Data cache writealloc
[0.00] Truncating RAM at a000-bfff to -afff (vmalloc region
overlap).
[0.00] OMAP4430 ES2.0
[0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000
[0.00] FIXME: omap44xx_sram_init not implemented
[0.00] PERCPU: Embedded 7 pages/cpu @c115f000 s6048 r8192 d14432 u32768
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 181248
[0.00] Kernel command line: console=ttyO2,115200n8 root=/dev/nfs rw
nfsroot=128.247.78.218:/home/x0091359/my-nfs/busybox,tcp,rsize=4096,wsize=4096
mem=4...@0x8000 mem=5...@0xa000 noinitrd ip=dh
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 458MB 512MB = 970MB total
[0.00] Memory: 712916k/712916k available, 18220k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB)
[0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB)
[0.00] vmalloc : 0xf080 - 0xf800 ( 120 MB)
[0.00] lowmem : 0xc000 - 0xf000 ( 768 MB)
[0.00] modules : 0xbf00 - 0xc000 ( 16 MB)
[0.00] .init : 0xc0008000 - 0xc0052000 ( 296 kB)
[0.00] .text : 0xc0052000 - 0xc0583a94 (5319 kB)
[0.00] .data : 0xc0584000 - 0xc05f9240 ( 469 kB)
[0.00] Hierarchical RCU implementation.
[0.00] RCU-based detection of stalled CPUs is disabled.
[0.00] NR_IRQS:402
[0.00] [ cut here ]
[0.00] WARNING: at arch/arm/mach-omap2/clockdomain.c:876
omap2_clkdm_deny_idle+0x4c/0x7c()
[0.00] clockdomain: OMAP4 wakeup/sleep dependency support is not yet
implemented
[0.00] Modules linked in:
[0.00] [c0063290] (unwind_backtrace+0x0/0xe4) from [c0093f60]
(warn_slowpath_common+0x4c/0x64)
[
[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Tony Lindgren t...@atomide.com [110110 10:51]:
* Russell King - ARM Linux li...@arm.linux.org.uk [110107 08:12]:
On Thu, Jan 06, 2011 at 12:40:54PM -0800, Tony Lindgren wrote:
Anyways, I can debug the DEBUG_LL booting issue further if the patch
I posted does not help.
This is what I ended up with earlier today to make the debug code work
both in the decompressor and in the kernel - once I had it working I
haven't bothered putting any more effort into it.
Hmm I have DEBUG_LL working fine (execept not for the uncompress code).
Looks like the only issue I have with my 4430 es1.0 blaze board is
that it won't boot reliably unless I disable l2x0_init.
Have you guys seen this issue?
Of course there are all kinds of omap4 warnings there, but after
disabling l2x0_init I was able to run apt-get dist-upgrade on my
board. This is with what I have queued up in omap-fixes.
Here's one more es1.0 fix after the recent USB changes.
Regards,
Tony
Author: Tony Lindgren t...@atomide.com
Date: Tue Jan 11 15:03:03 2011 -0800
omap4: Fix ULPI PHY init for ES1.0 SDP
Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
enable the ehci port on 4430SDP) added code to enable EHCI
support on 4430sdp board.
Looks like the ULPI pin does not seem to be muxed properly on ES1.0
SDP and this causes the system to reboot when the ULPI PHY is
enabled.
Fix this by muxing the pin, this is the same setting for
both ES1.0 and ES2.0. Also add checking for gpio_request.
Cc: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
@@ -576,11 +577,12 @@ static void __init omap_4430sdp_init(void)
omap4_twl6030_hsmmc_init(mmc);
/* Power on the ULPI PHY */
- if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
- /* FIXME: Assumes pad is already muxed for GPIO mode */
- gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, USBB1 PHY VMDM_3V3);
+ status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, USBB1 PHY VMDM_3V3);
+ if (status)
+ pr_err(%s: Could not get USBB1 PHY GPIO\n);
+ else
gpio_direction_output(OMAP4SDP_MDM_PWR_EN_GPIO, 1);
- }
+
usb_ehci_init(ehci_pdata);
usb_musb_init(musb_board_data);
--
To unsubscribe from this list: send the line unsubscribe 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 3/3] omap3: beaglexm: fix power on of DVI
* Nishanth Menon n...@ti.com [110111 09:12]:
From: Koen Kooi k...@beagleboard.org
TFP410 DVI chip is used to provide display out.
This chip is controlled by 2 lines:
LDO which supplies the power is controlled over gpio + 2
and the enable of the chip itself is done over gpio + 1
NOTE: the LDO is necessary for LED, serial blocks as well.
gpio + 1 was used to sense USB overcurrent in vanilla beagle.
Without this fix, the display would not function as the LDO
remains shut down.
[...@ti.com: split up, added descriptive changelogs]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Koen Kooi k...@beagleboard.org
---
arch/arm/mach-omap2/board-omap3beagle.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 673deb9..458aee4 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -293,9 +293,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
-
- gpio_request(gpio + 1, EHCI_nOC);
- gpio_direction_input(gpio + 1);
+ if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 1, EHCI_nOC);
+ gpio_direction_input(gpio + 1);
+ }
The return value for gpio_request must be checked.
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
@@ -316,6 +317,19 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+ /*
+ * gpio + 1 on Xm controls the TFP410's enable line (active low)
+ * gpio + 2 control varies depending on the board rev as follows:
+ * P7/P8 revisions(prototype): Camera EN
+ * A2+ revisions (production): LDO (supplies DVI, serial, led blocks)
+ */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 1, nDVI_PWR_EN);
+ gpio_direction_output(gpio + 1, 0);
+ gpio_request(gpio + 2, DVI_LDO_EN);
+ gpio_direction_output(gpio + 2, 1);
+ }
+
return 0;
}
Here too. I've applied the first two patches into devel-board branch,
but not this one.
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] omap3: igep3: Add omap_reserve functionality
* Enric Balletbo i Serra eballe...@gmail.com [110111 07:47]: This patch adds omap_reserve functionality to board-igep0030.c. This patch is in similar lines to commit id 71ee7dad9b6991, from Russell king Applying to devel-board. Tony Cc: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com --- arch/arm/mach-omap2/board-igep0030.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-igep0030.c b/arch/arm/mach-omap2/board-igep0030.c index 11b944f..4dc62a9 100644 --- a/arch/arm/mach-omap2/board-igep0030.c +++ b/arch/arm/mach-omap2/board-igep0030.c @@ -450,6 +450,7 @@ static void __init igep3_init(void) MACHINE_START(IGEP0030, IGEP OMAP3 module) .boot_params= 0x8100, + .reserve= omap_reserve, .map_io = omap3_map_io, .init_irq = igep3_init_irq, .init_machine = igep3_init, -- 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 v5 3/3] omap3: beaglexm: fix power on of DVI
Tony Lindgren had written, on 01/11/2011 05:23 PM, the following:
[..]
-
- gpio_request(gpio + 1, EHCI_nOC);
- gpio_direction_input(gpio + 1);
+ if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 1, EHCI_nOC);
+ gpio_direction_input(gpio + 1);
+ }
The return value for gpio_request must be checked.
Ack.
we can go down two paths:
a) I can redo this patch as in v6.patch (attached)
OR
b) we take this patch and do another one cleaning the function up -
gpio-check.patch
--
Regards,
Nishanth Menon
From d08694a8dff8506f1963d9249a89dae9fe508e70 Mon Sep 17 00:00:00 2001
From: Koen Kooi k...@beagleboard.org
Date: Thu, 6 Jan 2011 13:29:18 -0600
Subject: [PATCH v6 3/3] omap3: beaglexm: fix power on of DVI
TFP410 DVI chip is used to provide display out.
This chip is controlled by 2 lines:
LDO which supplies the power is controlled over gpio + 2
and the enable of the chip itself is done over gpio + 1
NOTE: the LDO is necessary for LED, serial blocks as well.
gpio + 1 was used to sense USB overcurrent in vanilla beagle.
Without this fix, the display would not function as the LDO
remains shut down.
[...@ti.com: split up, added descriptive changelogs]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Koen Kooi k...@beagleboard.org
---
arch/arm/mach-omap2/board-omap3beagle.c | 42 --
1 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 673deb9..28dfe8e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -273,6 +273,8 @@ static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int r;
+
if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
mmc[0].gpio_wp = -EINVAL;
} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
@@ -293,9 +295,16 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
-
- gpio_request(gpio + 1, EHCI_nOC);
- gpio_direction_input(gpio + 1);
+ if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
+ r = gpio_request(gpio + 1, EHCI_nOC);
+ if (!r) {
+ r = gpio_direction_input(gpio + 1);
+ if (r)
+gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err(%s: unable to configure EHCI_nOC\n, __func__);
+ }
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
@@ -316,6 +325,33 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+ /*
+ * gpio + 1 on Xm controls the TFP410's enable line (active low)
+ * gpio + 2 control varies depending on the board rev as follows:
+ * P7/P8 revisions(prototype): Camera EN
+ * A2+ revisions (production): LDO (supplies DVI, serial, led blocks)
+ */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ r = gpio_request(gpio + 1, nDVI_PWR_EN);
+ if (!r) {
+ r = gpio_direction_output(gpio + 1, 0);
+ if (r)
+gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err(%s: unable to configure nDVI_PWR_EN\n,
+__func__);
+ r = gpio_request(gpio + 2, DVI_LDO_EN);
+ if (!r) {
+ r = gpio_direction_output(gpio + 2, 1);
+ if (r)
+gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err(%s: unable to configure DVI_LDO_EN\n,
+__func__);
+ }
+
return 0;
}
--
1.6.3.3
From f16524ab1cfba7d2a9bd0a8ef5a577a1fb41bfff Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 11 Jan 2011 17:51:47 -0600
Subject: [PATCH] omap3: beagle: check gpio returns in gpio_setup
gpio request and set of directions need checks of return value
to ensure that operation succeeded or not.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 49 ---
1 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 458aee4..fc598d3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -273,6 +273,8 @@ static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int r;
+
if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
mmc[0].gpio_wp = -EINVAL;
} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
@@ -294,19 +296,29 @@ static int beagle_twl_gpio_setup(struct device *dev,
* power switch and overcurrent detect
*/
if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
- gpio_request(gpio + 1, EHCI_nOC);
- gpio_direction_input(gpio + 1);
+ r = gpio_request(gpio + 1, EHCI_nOC);
+ if (!r) {
+ r = gpio_direction_input(gpio + 1);
+ if (r)
+gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err(%s:
[PATCH 0/0] RFC: ARM: Thumb-2: Symbol manipulation macros for function body copying
For at least one board (omap3), some functions are copied from
their link-time location into other memory at run-time.
This is a plausible thing to do if, for example, the board
might need to do something like manipulating the SDRAM
controller configuration during power management operations.
Such code may not be able to execute from the SDRAM itself.
In Thumb-2, copying function bodies is not straightforward:
for Thumb symbols, bit 0 is set by the toolchain, and so
a function symbol can't be used directly as a base address
for memcpy: this leads to an off-by-one error, resulting in
garbage instructions in the destination buffer.
The obvious solution is to mask off this bit when calling
memcpy() and then insert the bit into the address of the
target buffer, in order to derive a pointer which can be
used to call the copied function in the correct instruction
set. However, in practice the compiler may optimise this
operation away. This seems wrong, but having discussed this
with compiler folks I believe it's not a compiler bug: rather,
C doesn't specifiy what happens when casting function pointers
and attempting to do arithmetic on them. So some surprising
optimisations can happen.
To make it easier to deal with cases like this, I've had a
go at writing some macros to make copying function bodies
easier, while being robust for ARM and Thumb-2.
In particular, the required type-casts are implemented as
empty asm() blocks, to ensure that the compiler makes no
assumptions about the result.
These macros just help with the address manipulations: e.g.:
extern int scary_function(int a, char *b);
extern const int size_of_scary_function;
extern void *scary_memory_buf;
int (*runtime_scary_function)(int a, char *b);
runtime_scary_function = FSYM_REBASE(
scary_function,
memcpy(scary_memory_buf, FSYM_BASE(scary_function),
size_of_scary_function));
This is quite a lot more readable than the explicit code,
and gives the correct result (modulo bugs in my patch...)
It's still necessary to do the appropriate cache-flushing
before runtime_scary_function is actually called. Also,
it's not possible to determine the size of a function from
C code. This must be done by other means, such as adding
extra symbols in the assembler code where scary_function is
defined.
I can't comment on how widespread the requirement for function
body copying is in the arch/arm/ tree, however.
Signed-off-by: Dave Martin dave.mar...@linaro.org
---
KernelVersion: next-20110111
arch/arm/include/asm/unified.h | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
index bc63116..636a765 100644
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -24,6 +24,32 @@
.syntax unified
#endif
+#ifndef __ASSEMBLY__
+#include linux/types.h
+#define __funcp_to_uint(funcp) ({ \
+ uintptr_t __result; \
+ \
+ asm( : =r (__result) : 0 (funcp));\
+ __result; \
+ })
+#define __uint_to_funcp(i, funcp) ({ \
+ typeof(funcp) __result; \
+ \
+ asm( : =r (__result) : 0 (i));\
+ __result; \
+ })
+#define FSYM_REBASE(funcp, dest_buf) \
+ __uint_to_funcp((uintptr_t)(dest_buf) | FSYM_TYPE(funcp), funcp)
+
+#ifdef CONFIG_THUMB2_KERNEL
+#define FSYM_BASE(funcp) ((void *)(__funcp_to_uint(funcp) ~(uintptr_t)1))
+#define FSYM_TYPE(funcp) (__funcp_to_uint(funcp) 1)
+#else /* !CONFIG_THUMB2_KERNEL */
+#define FSYM_BASE(funcp) ((void *)__funcp_to_uint(funcp))
+#define FSYM_TYPE(funcp) 0
+#endif /* !CONFIG_THUMB2_KERNEL */
+#endif /* !__ASSEMBLY__ */
+
#ifdef CONFIG_THUMB2_KERNEL
#if __GNUC__ 4
--
1.7.1
*** BLURB HERE ***
Dave Martin (1):
ARM: Thumb-2: Symbol manipulation macros for function body copying
arch/arm/include/asm/unified.h | 26 ++
1 files changed, 26 insertions(+), 0 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
[PATCH 1/1] ARM: Thumb-2: Symbol manipulation macros for function body copying
In low-level board support code, there is sometimes a need to
copy a function body to another location at run-time.
A straightforward call to memcpy doesn't work in Thumb-2,
because bit 0 of external Thumb function symbols is set to 1,
indicating that the function is Thumb. Without corrective
measures, this will cause an off-by-one copy, and the copy
may be called using the wrong instruction set.
This patch adds macros to help with such cases.
Particular care is needed, because C doesn't guarantee any
defined behaviour when casting a function pointer to any other
type. This has been observed to lead to strange optimisation
side-effects when doing the arithmetic which is required in
order to copy/move function bodies correctly in Thumb-2.
Signed-off-by: Dave Martin dave.mar...@linaro.org
---
KernelVersion: next-20110111
arch/arm/include/asm/unified.h | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
index bc63116..636a765 100644
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -24,6 +24,32 @@
.syntax unified
#endif
+#ifndef __ASSEMBLY__
+#include linux/types.h
+#define __funcp_to_uint(funcp) ({ \
+ uintptr_t __result; \
+ \
+ asm( : =r (__result) : 0 (funcp));\
+ __result; \
+ })
+#define __uint_to_funcp(i, funcp) ({ \
+ typeof(funcp) __result; \
+ \
+ asm( : =r (__result) : 0 (i));\
+ __result; \
+ })
+#define FSYM_REBASE(funcp, dest_buf) \
+ __uint_to_funcp((uintptr_t)(dest_buf) | FSYM_TYPE(funcp), funcp)
+
+#ifdef CONFIG_THUMB2_KERNEL
+#define FSYM_BASE(funcp) ((void *)(__funcp_to_uint(funcp) ~(uintptr_t)1))
+#define FSYM_TYPE(funcp) (__funcp_to_uint(funcp) 1)
+#else /* !CONFIG_THUMB2_KERNEL */
+#define FSYM_BASE(funcp) ((void *)__funcp_to_uint(funcp))
+#define FSYM_TYPE(funcp) 0
+#endif /* !CONFIG_THUMB2_KERNEL */
+#endif /* !__ASSEMBLY__ */
+
#ifdef CONFIG_THUMB2_KERNEL
#if __GNUC__ 4
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] omap3: beaglexm: fix power on of DVI
* Nishanth Menon n...@ti.com [110111 15:54]:
Tony Lindgren had written, on 01/11/2011 05:23 PM, the following:
[..]
-
- gpio_request(gpio + 1, EHCI_nOC);
- gpio_direction_input(gpio + 1);
+ if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 1, EHCI_nOC);
+ gpio_direction_input(gpio + 1);
+ }
The return value for gpio_request must be checked.
Ack.
we can go down two paths:
a) I can redo this patch as in v6.patch (attached)
Yes let's do that, one comment below though..
OR
b) we take this patch and do another one cleaning the function up -
gpio-check.patch
That can be done later.
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ r = gpio_request(gpio + 1, nDVI_PWR_EN);
+ if (!r) {
+ r = gpio_direction_output(gpio + 1, 0);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err(%s: unable to configure nDVI_PWR_EN\n,
+ __func__);
+ r = gpio_request(gpio + 2, DVI_LDO_EN);
+ if (!r) {
+ r = gpio_direction_output(gpio + 2, 1);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err(%s: unable to configure DVI_LDO_EN\n,
+ __func__);
+ }
+
Should the second gpio_free be gpio + 2 instead of gpio + 1?
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 v5 3/3] omap3: beaglexm: fix power on of DVI
Tony Lindgren had written, on 01/11/2011 06:15 PM, the following:
* Nishanth Menon n...@ti.com [110111 15:54]:
Tony Lindgren had written, on 01/11/2011 05:23 PM, the following:
[..]
-
- gpio_request(gpio + 1, EHCI_nOC);
- gpio_direction_input(gpio + 1);
+ if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 1, EHCI_nOC);
+ gpio_direction_input(gpio + 1);
+ }
The return value for gpio_request must be checked.
Ack.
we can go down two paths:
a) I can redo this patch as in v6.patch (attached)
Yes let's do that, one comment below though..
OR
b) we take this patch and do another one cleaning the function up -
gpio-check.patch
That can be done later.
ok
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ r = gpio_request(gpio + 1, nDVI_PWR_EN);
+ if (!r) {
+ r = gpio_direction_output(gpio + 1, 0);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err(%s: unable to configure nDVI_PWR_EN\n,
+ __func__);
+ r = gpio_request(gpio + 2, DVI_LDO_EN);
+ if (!r) {
+ r = gpio_direction_output(gpio + 2, 1);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err(%s: unable to configure DVI_LDO_EN\n,
+ __func__);
+ }
+
Should the second gpio_free be gpio + 2 instead of gpio + 1?
oops.. yep. will fix and send out a v6 for this alone. thanks for the check.
--
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
[PATCH v6.1 3/3] omap3: beaglexm: fix power on of DVI
From: Koen Kooi k...@beagleboard.org
TFP410 DVI chip is used to provide display out.
This chip is controlled by 2 lines:
LDO which supplies the power is controlled over gpio + 2
and the enable of the chip itself is done over gpio + 1
NOTE: the LDO is necessary for LED, serial blocks as well.
gpio + 1 was used to sense USB overcurrent in vanilla beagle.
Without this fix, the display would not function as the LDO
remains shut down.
[...@ti.com: split up, added descriptive changelogs]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Koen Kooi k...@beagleboard.org
---
Posting the last of the patches of this series
v6.1: formal submission:
added gpio error checks
v5: http://marc.info/?t=12947661696r=1w=2
arch/arm/mach-omap2/board-omap3beagle.c | 42 --
1 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 673deb9..2ed8040 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -273,6 +273,8 @@ static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int r;
+
if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
mmc[0].gpio_wp = -EINVAL;
} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
@@ -293,9 +295,16 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
-
- gpio_request(gpio + 1, EHCI_nOC);
- gpio_direction_input(gpio + 1);
+ if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
+ r = gpio_request(gpio + 1, EHCI_nOC);
+ if (!r) {
+ r = gpio_direction_input(gpio + 1);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err(%s: unable to configure EHCI_nOC\n, __func__);
+ }
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
@@ -316,6 +325,33 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+ /*
+* gpio + 1 on Xm controls the TFP410's enable line (active low)
+* gpio + 2 control varies depending on the board rev as follows:
+* P7/P8 revisions(prototype): Camera EN
+* A2+ revisions (production): LDO (supplies DVI, serial, led blocks)
+*/
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ r = gpio_request(gpio + 1, nDVI_PWR_EN);
+ if (!r) {
+ r = gpio_direction_output(gpio + 1, 0);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err(%s: unable to configure nDVI_PWR_EN\n,
+ __func__);
+ r = gpio_request(gpio + 2, DVI_LDO_EN);
+ if (!r) {
+ r = gpio_direction_output(gpio + 2, 1);
+ if (r)
+ gpio_free(gpio + 2);
+ }
+ if (r)
+ pr_err(%s: unable to configure DVI_LDO_EN\n,
+ __func__);
+ }
+
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v2 2/4] ASoC: DMIC codec: Adding a generic DMIC codec
On Thu, 2011-01-06 at 08:00 -0600, David Lambert wrote: This codec is to be used by the DMIC driver to control the DMIC codec. This driver will be used on future implementations of the DMIC driver to support codec specific features. At this time, the codec driver just registers the codec DAI. Signed-off-by: David Lambert dlamb...@ti.com --- sound/soc/codecs/Kconfig |3 ++ sound/soc/codecs/Makefile |2 + sound/soc/codecs/dmic.c | 81 + 3 files changed, 86 insertions(+), 0 deletions(-) create mode 100644 sound/soc/codecs/dmic.c Applied. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6.1 3/3] omap3: beaglexm: fix power on of DVI
* Nishanth Menon n...@ti.com [110111 16:22]: From: Koen Kooi k...@beagleboard.org TFP410 DVI chip is used to provide display out. This chip is controlled by 2 lines: LDO which supplies the power is controlled over gpio + 2 and the enable of the chip itself is done over gpio + 1 NOTE: the LDO is necessary for LED, serial blocks as well. gpio + 1 was used to sense USB overcurrent in vanilla beagle. Without this fix, the display would not function as the LDO remains shut down. Thanks, applying. 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: Issues with ADATA SD cards on OMAP? -- dto calculation??
On Sat, Jan 8, 2011 at 10:04 PM, Steve Sakoman sako...@gmail.com wrote:
I've recently been testing memory card performance to identify the
best performing brands/models.
As expected, I found a huge difference in performance between brands.
What I didn't expect to find, however, was a brand (ADATA) that
doesn't seem to play well with the 2.6.36 kernel on OMAP3 hardware.
I'm wondering if this failure might be exposing an issue in the OMAP
mmc driver/hw setup.
I tested both 4GB and 8GB versions of the ADATA Class 6 cards. I was
not able to boot successfully from either card on both Overo and
Beagle hardware (both 35xx and 37xx versions were tested).
The error was the same in all cases: x-load, u-boot, and the kernel
were all loaded successfully from SD, but the kernel was not able to
mount the rootfs:
On the suggestion of Steve Kipisz of TI I tried increasing the value
of dto in the set_data_timeout function of
drivers/mmc/host/omap_hsmmc.c
Hard coding dto to the max value of 14 appears to fix the timeout
errors with ADATA brand cards.
Does anyone understand the rationale behind the current dti
computation? For reference, here is the code:
if (timeout) {
while ((timeout 0x8000) == 0) {
dto += 1;
timeout = 1;
}
dto = 31 - dto;
timeout = 1;
if (timeout dto)
dto += 1;
if (dto = 13)
dto -= 13;
else
dto = 0;
if (dto 14)
dto = 14;
}
I am far from certain that just increasing dto (let alone by what
amount!) is the proper fix, since the timeout may be just a symptom of
a more fundamental timing/voltage issue.
I have a few more cards to test that failed 100% of the time with the
standard code, but I suspect that they are likely to work now too.
Any thoughts?
Steve
Waiting for root device /dev/mmcblk0p2...
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new high speed SDHC card at address 0260
mmcblk0: mmc0:0260 SD 3.75 GiB
mmcblk0: p1 p2
EXT3-fs: barriers not enabled
kjournald starting. Commit interval 5 seconds
EXT3-fs (mmcblk0p2): using internal journal
EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) on device 179:2.
devtmpfs: mounted
Freeing init memory: 168K
INIT: version 2.86 booting
Please wait: booting...
Starting udev
Remounting root file system...
mmcblk0: error -110 sending read/write command, response 0x900, card
status 0xe00
mmcblk0: error -110 transferring data, sector 3556505, nr 8, card status 0xc00
end_request: I/O error, dev mmcblk0, sector 3556512
Buffer I/O error on device mmcblk0p2, logical block 426490
lost page write due to I/O error on mmcblk0p2
mmcblk0: error -110 sending read/write command, response 0x900, card
status 0xe00
mmcblk0: error -110 transferring data, sector 4076825, nr 8, card status 0xc00
end_request: I/O error, dev mmcblk0, sector 4076832
Buffer I/O error on device mmcblk0p2, logical block 491530
lost page write due to I/O error on mmcblk0p2
mmcblk0: error -110 sending read/write command, response 0x900, card
status 0xe00
mmcblk0: error -110 transferring data, sector 4126233, nr 8, card status 0xc00
end_request: I/O error, dev mmcblk0, sector 4126234
Buffer I/O error on device mmcblk0p2, logical block 497706
lost page write due to I/O error on mmcblk0p2
And so on, with many more mmc errors.
If I reset and try again, things go wrong even sooner:
Waiting for root device /dev/mmcblk0p2...
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new high speed SDHC card at address 0260
mmcblk0: mmc0:0260 SD 3.75 GiB
mmcblk0: p1 p2
EXT3-fs: barriers not enabled
mmcblk0: error -110 sending read/write command, response 0x900, card
status 0xe00
mmcblk0: error -110 transferring data, sector 147545, nr 8, card status 0xc00
end_request: I/O error, dev mmcblk0, sector 147552
Buffer I/O error on device mmcblk0p2, logical block 370
lost page write due to I/O error on mmcblk0p2
The ADATA cards seem to work with no issues on my desktop system.
Has anyone else run into this issue? Any theories on where to start looking?
FWIW, there is this thread on the beagleboard list discussing issues
with mmc writes:
http://groups.google.com/group/beagleboard/browse_thread/thread/0083724ff7e54c58/f55578bb1c1379db#f55578bb1c1379db
In this thread Gerald Coley speculates that the driver may be setting
the mmc1 voltage to 3.0V rather than 3.15V.
Regards,
Steve
PS: For those who might be interested in the microSD card performance tests:
http://www.sakoman.com/OMAP/microsd-card-perfomance-test-results.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: Issues with ADATA SD cards on OMAP? -- dto calculation??
On Jan 12, 2011, at 9:58 AM, Steve Sakoman wrote: On the suggestion of Steve Kipisz of TI I tried increasing the value of dto in the set_data_timeout function of drivers/mmc/host/omap_hsmmc.c Hard coding dto to the max value of 14 appears to fix the timeout errors with ADATA brand cards. On some products that use the Gumstix Overo, we found microSD card failures during extended NAND read/write tests. Again, the fix suggested by TI was to increase the dto timeout value to 14. The issues were more apparently with cheap microSD cards, not necessarily the faster class 4 variety. Using a SanDisk class 2 works ok. I used a SanDisk class 4 for development. The microSD card gets corrupted when running endurance tests, with failures occurring with the microSD card in about 3 to 4 days of doing continuous read-writes to the microSD card. Elvis -- To unsubscribe from this list: send the line unsubscribe 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: Issues with ADATA SD cards on OMAP?
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Steve Sakoman
Sent: Sunday, January 09, 2011 10:45 PM
To: Elvis Dowson
Cc: linux-omap Mailing List
Subject: Re: Issues with ADATA SD cards on OMAP?
On Sun, Jan 9, 2011 at 9:07 AM, Elvis Dowson elvis.dow...@mac.com wrote:
Hi Steve,
On Jan 9, 2011, at 9:00 PM, Steve Sakoman wrote:
mmcblk0: error -110 sending read/write command, response 0x900, card
status 0xe00
Error -110 is ETIMEOUT.
The card might be getting detected but not powering up, perhaps?
something to do with
voltage regulator setup or probably a bad mmc hardware port?
Not likely to be bad hardware since it fails the same way on multiple
Overo and Beagle boards.
And not likely to be a bad SD card, since the cards work perfectly on
my desktop and laptop.
I suspect something marginal in the mmc interface hw/config. If you
look at the schematics for most boards the mmc card is directly
connected to the OMAP for signal lines, and the twl4030 for power.
As such, I'm not surprised that these cards fail with every OMAP3
board I've tried.
I'm using a 2GB class 4 SanDisk microSD card with a custom beagle board,
and tried it with
android-2.6.32 kernel as well as mainline 2.6.37-rc7 kernel, it worked
fine.
Sure, I have tons of SanDisk cards that work perfectly (and always
have). It is the brand new, just out of the box Sandisk that fails.
[Ghorai]
We also experienced the same issue using 32GB SD card for omap3 and omap4.
And the problem is seen is that DTO value (in SYSCTL) is not current
in following function.
So add the following modification and please update the status.
And we will submit proper patch towards the same.
static void set_data_timeout(..){
...
cycle_ns = 10 / (clk_get_rate(host-fclk) / clkd);
timeout = timeout_ns / cycle_ns;
timeout += timeout_clks;
+ timeout *=2;
if (timeout) {
...
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] X86/perf: fix power:cpu_idle double end events and throw cpu_idle events from the cpuidle layer
I'm happy to see the trace point move up into cpuidle from intel_idle. If somebody is picking this up in a perf tree, Acked-by: Len Brown len.br...@intel.com else I can put it in the idle tree, let me know. thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe 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/9] cpuidle: Introduce .abbr (abbrevation) for cpuidle states
I'm not fond of inventing a new 3-character abbreviation field for every state because display tools can't handle the existing 16-character name field. If the display tools can only handle 3 characters, then why not have them simply use the 1st 3 characters of the existing name field? If that is not unique, then re-arrange the strings so that it is unique... Of course the ACPI part of this patch will not apply, as it depends on patch 1 in this series, which was erroneous. For ACPI, the existing name field is already fine, as C%d fits into 3 characters. thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
