Re: [PATCH] ARM: omap4: Pass core and wakeup mux tables to omap4_mux_init
* Colin Cross [110531 21:46]: > On Tue, May 31, 2011 at 5:42 AM, Tony Lindgren wrote: > > * Colin Cross [110504 14:54]: > >> OMAP4 contains two separate instances of the padconf registers, > >> one in the core system config and one in the wakeup system config. > >> Pass in two tables to apply the correct values to each instance. > > > > Hmm good catch thanks. Will queue this as a fix. > > This patch doesn't work without another fix to allow NULL to be passed > to omap4_mux_init. Do you prefer allowing NULL, or adding empty > board_wkup_mux arrays to every board file? I have a patch for the > first option. OK, saw that patch and adding to fixes. Passing NULL here is fine. 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: beagle: add support for beagleboard xM revision C
* Koen Kooi [110531 21:09]:
>
> Op 30 mei 2011, om 16:34 heeft Tony Lindgren het volgende geschreven:
>
> > Hi,
> >
> > * Koen Kooi [110527 06:28]:
> >>
> >> @@ -123,9 +126,13 @@ static void __init omap3_beagle_init_rev(void)
> >>printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
> >>omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
> >>break;
> >> + case 2:
> >> + printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
> >> + omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
> >> + break;
> >>default:
> >>printk(KERN_INFO "OMAP3 Beagle Rev: unknown %hd\n", beagle_rev);
> >> - omap3_beagle_version = OMAP3BEAGLE_BOARD_UNKN;
> >> + omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
> >>}
> >> }
> >
> > Maybe just set up static struct omap3_beagle that contains the
> > various things to initialize. Then initialize it in omap3_beagle_init_rev
> > above.
> >
> > Otherwise we'll end up adding more and more omap3_beagle_get_rev and
> > cpu_is_omap tests to this file and it will become hard to maintain.
> >
> >> @@ -253,7 +260,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
> >> {
> >>int r, usb_pwr_level;
> >>
> >> - if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
> >> + if (cpu_is_omap3630()) {
> >>mmc[0].gpio_wp = -EINVAL;
> >>} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
> >>(omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
> >
> > This would become:
> >
> > mmc[0].gpio_wp = beagle.gpio_wp;
> >
> >> @@ -275,11 +282,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
> >> * high / others active low)
> >> * DVI reset GPIO is different between beagle revisions
> >> */
> >> - if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
> >> - usb_pwr_level = GPIOF_OUT_INIT_HIGH;
> >> + if (cpu_is_omap3630()) {
> >>beagle_dvi_device.reset_gpio = 129;
> >>/*
> >> - * gpio + 1 on Xm controls the TFP410's enable line (active low)
> >> + * gpio + 1 on xM controls the TFP410's enable line (active low)
> >> * gpio + 2 control varies depending on the board rev as below:
> >> * P7/P8 revisions(prototype): Camera EN
> >> * A2+ revisions (production): LDO (DVI, serial, led blocks)
> >
> > This would be just:
> >
> > usb_pwr_level = beagle.usb_pwr_level;
> >
> > And so on.
>
> Tony, thanks for the feedback! The change you want is a bit too much for my C
> knowledge, but Joel will but picking it up from here.
Hmm, not much there to it actually :) I'm sure you too can do it
little help from Joel.
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
[PATCH 2/3] OMAP2+: fix compilation warnings.
Fix below compilation warnings.
arch/arm/mach-omap2/omap_hwmod.c: In function 'omap_hwmod_for_each':
arch/arm/mach-omap2/omap_hwmod.c:1631: warning: 'ret' may be used uninitialized
in this function
arch/arm/mach-omap2/mux.c: In function 'omap_mux_get_gpio':
arch/arm/mach-omap2/mux.c:917: warning: 'm' may be used uninitialized in this
function
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/mux.c|2 +-
arch/arm/mach-omap2/omap_hwmod.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index a4ab1e3..b4f9066 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -906,7 +906,7 @@ static struct omap_mux *omap_mux_get_by_gpio(
u16 omap_mux_get_gpio(int gpio)
{
struct omap_mux_partition *partition;
- struct omap_mux *m;
+ struct omap_mux *m = NULL;
list_for_each_entry(partition, &mux_partitions, node) {
m = omap_mux_get_by_gpio(partition, gpio);
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e034294..293fa6c 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1628,7 +1628,7 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh,
void *data),
void *data)
{
struct omap_hwmod *temp_oh;
- int ret;
+ int ret = 0;
if (!fn)
return -EINVAL;
--
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 1/3] OMAP2+: Fix debug section mistmatch warnings
Fix the below debug section mismatch warnings.
while compiling kernel with CONFIG_DEBUG_SECTION_MISMATCH=y
WARNING: vmlinux.o(.data+0x38638): Section mismatch in reference from the
variable serial*_data to the (unknown reference) .init.data:(unknown)
The variable serial*_data references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Reported-by: Nishant Kamat
Signed-off-by: Govindraj.R
---
Based on 3.0-rc1
arch/arm/mach-omap2/board-3430sdp.c|6 +++---
arch/arm/mach-omap2/board-4430sdp.c|6 +++---
arch/arm/mach-omap2/board-omap4panda.c |6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ae2963a..5dac974 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -622,19 +622,19 @@ static struct omap_device_pad serial3_pads[] __initdata =
{
OMAP_MUX_MODE0),
};
-static struct omap_board_data serial1_data = {
+static struct omap_board_data serial1_data __initdata = {
.id = 0,
.pads = serial1_pads,
.pads_cnt = ARRAY_SIZE(serial1_pads),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 73fa90b..f90623d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -681,19 +681,19 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 90485fc..84a8e4a 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -526,19 +526,19 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
--
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/RFC 2/4] OMAP2: PM debug: remove register dumping
Hi Patrick, "Titiano, Patrick" writes: [...] >> >> OK for this change. Is it the intention to use the omapconf tool as >> the replacement for the regs dump code? > > Sorry but omapconf is run from userspace, it cannot be used to dump > PRCM registers right before and after MPU WFI. > Right, taking register snapshots is currently beyond the scope of omapconf. However, as I suggested earlier in this thread, if we had a new driver with read/write interface where register snapshots are saved, I imagine adopting omapconf to read from such an interface for dumping register snapshots would be relatively easy, right? Kevin [1] again, I haven't really thought much about this, but something like; write an address to /dev/foo, then reading 'len' bytes from /dev/foo would give back the snapshot data (if any) starting from that address. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 2/4] OMAP2: PM debug: remove register dumping
Santosh Shilimkar writes: > On 5/27/2011 4:32 AM, Kevin Hilman wrote: >> Signed-off-by: Kevin Hilman > > Do you plan to keep wroking the patch which dumps registers > before and after WFI ? No. I haven't thought through all the details yet, but I'm hoping that dropping this feature will "encourage" others to help think about it as well. ;) Ideally, I'd like to see this handled by perf/ftrace. We now have tracepoints for clock, clockdomain and powerdomain events. Maybe adding additional data for each of these tracepoints which snapshots some key registers values would be useful. Then, visualizing with tools like pytimechart or kernelshark could be done. Another option would be a new driver which adds a way to snapshot registers into a hash-table based on address (maybe triggered by the existing tracepoints.) This data could then be readable from userspace via the drivers read/write interface, and displayed with a tool that already knows about all the registers/bitfields etc. (e.g. omapconf.) I'd guess the the latter is probably prefered since all the register & bitfield knowlege is already in a tool like omapconf. > Ofcourse this patch is in your pm-debug branch. Right, I'll be dropping that branch. > For this change > Acked-by: Santosh Shilimkar Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: PM: omap_device: fix device power domain callbacks
After commit 4d27e9dcff00a6425d779b065ec8892e4f391661 (PM: Make power
domain callbacks take precedence over subsystem ones), the power
domain callbacks need to call the driver callbacks instead of relying
on the default subsystem (in this case, platform_bus) to handle the
driver callbacks.
Validated on 3430/n900, 3530/Overo.
Signed-off-by: Kevin Hilman
---
Will be queued in my for_3.0/pm-fixes branch unless there are objections.
arch/arm/plat-omap/omap_device.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index a37b8eb..49fc0df 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -84,6 +84,7 @@
#include
#include
#include
+#include
#include
#include
@@ -539,20 +540,34 @@ int omap_early_device_register(struct omap_device *od)
static int _od_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
+ int ret;
+
+ ret = pm_generic_runtime_suspend(dev);
+
+ if (!ret)
+ omap_device_idle(pdev);
+
+ return ret;
+}
- return omap_device_idle(pdev);
+static int _od_runtime_idle(struct device *dev)
+{
+ return pm_generic_runtime_idle(dev);
}
static int _od_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
- return omap_device_enable(pdev);
+ omap_device_enable(pdev);
+
+ return pm_generic_runtime_resume(dev);
}
static struct dev_power_domain omap_device_power_domain = {
.ops = {
.runtime_suspend = _od_runtime_suspend,
+ .runtime_idle = _od_runtime_idle,
.runtime_resume = _od_runtime_resume,
USE_PLATFORM_PM_SLEEP_OPS
}
--
1.7.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: [RFC PATCH v4] Consolidate SRAM support
On Tue, May 31, 2011 at 10:39:48PM +0530, Nori, Sekhar wrote: > I also found some check patch errors. Feel free to merge > the attached patch. And this introduces another style issue... > diff --git a/arch/arm/plat-mxc/include/mach/iram.h > b/arch/arm/plat-mxc/include/mach/iram.h > index 8279c47..aae5e35 100644 > --- a/arch/arm/plat-mxc/include/mach/iram.h > +++ b/arch/arm/plat-mxc/include/mach/iram.h > @@ -31,7 +31,7 @@ static inline void *iram_alloc(size_t size, phys_addr_t > *phys) > > *phys = gen_pool_virt_to_phys(iram_pool, addr); > > - return (void*)addr; > + return (void *) addr; The style here is: return (void *)addr; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: omap2+: mux: Allow board mux settings to be NULL
OMAP4 has two mux instances, and the board may not have settings
for one of them. Allow the board file to pass NULL for an
instance's mux settings, which will initialize the mux instance
but skip writing board settings.
Signed-off-by: Colin Cross
---
arch/arm/mach-omap2/mux.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index a4ab1e3..6788dbc 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -83,6 +83,9 @@ void omap_mux_write(struct omap_mux_partition *partition, u16
val,
void omap_mux_write_array(struct omap_mux_partition *partition,
struct omap_board_mux *board_mux)
{
+ if (!board_mux)
+ return;
+
while (board_mux->reg_offset != OMAP_MUX_TERMINATOR) {
omap_mux_write(partition, board_mux->value,
board_mux->reg_offset);
--
1.7.4.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] ARM: omap4: Pass core and wakeup mux tables to omap4_mux_init
On Tue, May 31, 2011 at 5:42 AM, Tony Lindgren wrote: > * Colin Cross [110504 14:54]: >> OMAP4 contains two separate instances of the padconf registers, >> one in the core system config and one in the wakeup system config. >> Pass in two tables to apply the correct values to each instance. > > Hmm good catch thanks. Will queue this as a fix. This patch doesn't work without another fix to allow NULL to be passed to omap4_mux_init. Do you prefer allowing NULL, or adding empty board_wkup_mux arrays to every board file? I have a patch for the first option. -- To unsubscribe from this list: send the line "unsubscribe 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: beagle: add support for beagleboard xM revision C
Op 30 mei 2011, om 16:34 heeft Tony Lindgren het volgende geschreven:
> Hi,
>
> * Koen Kooi [110527 06:28]:
>>
>> @@ -123,9 +126,13 @@ static void __init omap3_beagle_init_rev(void)
>> printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
>> omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
>> break;
>> +case 2:
>> +printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
>> +omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
>> +break;
>> default:
>> printk(KERN_INFO "OMAP3 Beagle Rev: unknown %hd\n", beagle_rev);
>> -omap3_beagle_version = OMAP3BEAGLE_BOARD_UNKN;
>> +omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
>> }
>> }
>
> Maybe just set up static struct omap3_beagle that contains the
> various things to initialize. Then initialize it in omap3_beagle_init_rev
> above.
>
> Otherwise we'll end up adding more and more omap3_beagle_get_rev and
> cpu_is_omap tests to this file and it will become hard to maintain.
>
>> @@ -253,7 +260,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
>> {
>> int r, usb_pwr_level;
>>
>> -if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
>> +if (cpu_is_omap3630()) {
>> mmc[0].gpio_wp = -EINVAL;
>> } else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
>> (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
>
> This would become:
>
> mmc[0].gpio_wp = beagle.gpio_wp;
>
>> @@ -275,11 +282,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
>> * high / others active low)
>> * DVI reset GPIO is different between beagle revisions
>> */
>> -if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
>> -usb_pwr_level = GPIOF_OUT_INIT_HIGH;
>> +if (cpu_is_omap3630()) {
>> beagle_dvi_device.reset_gpio = 129;
>> /*
>> - * gpio + 1 on Xm controls the TFP410's enable line (active low)
>> + * gpio + 1 on xM controls the TFP410's enable line (active low)
>> * gpio + 2 control varies depending on the board rev as below:
>> * P7/P8 revisions(prototype): Camera EN
>> * A2+ revisions (production): LDO (DVI, serial, led blocks)
>
> This would be just:
>
> usb_pwr_level = beagle.usb_pwr_level;
>
> And so on.
Tony, thanks for the feedback! The change you want is a bit too much for my C
knowledge, but Joel will but picking it up from here.
regards,
Koen--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH v4] Consolidate SRAM support
Hi Jean-Christophe,
On Thu, May 26, 2011 at 06:32:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
> From: Russell King - ARM Linux
>
> We have two SoCs using SRAM, both with their own allocation systems,
> and both with their own ways of copying functions into the SRAM.
>
> Let's unify this before we have additional SoCs re-implementing this
> obviously common functionality themselves.
>
> For this use the generic allocator and the newly introduce
> gen_pool_add_virt and gen_pool_virt_to_phys
>
> Uio_pruss should probably take the SRAM pool pointer via
> platform data so that it doesn't have to include Davinci specific
> includes.
>
> Signed-off-by: Russell King
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
> Cc: Sekhar Nori
> Cc: Kevin Hilman
> Cc: Tony Lindgren
> Cc: Sascha Hauer
I tested this on DA850 using suspend-to-RAM and audio, it works
well!
> arch/arm/Kconfig |2 +
> arch/arm/mach-davinci/da850.c |2 +-
> arch/arm/mach-davinci/dm355.c |2 +-
> arch/arm/mach-davinci/dm365.c |2 +-
> arch/arm/mach-davinci/dm644x.c |2 +-
> arch/arm/mach-davinci/dm646x.c |2 +-
> arch/arm/mach-davinci/include/mach/common.h|2 +-
> arch/arm/mach-davinci/include/mach/sram.h | 13 +
> arch/arm/mach-davinci/pm.c | 21 +++
> arch/arm/mach-davinci/sram.c | 57 +--
> arch/arm/plat-mxc/include/mach/iram.h | 28 --
> .../plat-mxc/{include/mach/iram.h => iram_alloc.c} | 40 --
I had trouble applying the plat-mxc stuff on v3.0-rc1.
Can you please check?
I also found some check patch errors. Feel free to merge
the attached patch.
With these, please add my:
Acked-by: Sekhar Nori
Thanks,
Sekhar
8<---
diff --git a/arch/arm/plat-mxc/include/mach/iram.h
b/arch/arm/plat-mxc/include/mach/iram.h
index 8279c47..aae5e35 100644
--- a/arch/arm/plat-mxc/include/mach/iram.h
+++ b/arch/arm/plat-mxc/include/mach/iram.h
@@ -31,7 +31,7 @@ static inline void *iram_alloc(size_t size, phys_addr_t *phys)
*phys = gen_pool_virt_to_phys(iram_pool, addr);
- return (void*)addr;
+ return (void *) addr;
}
static inline void iram_free(void *addr, size_t size)
diff --git a/arch/arm/plat-omap/include/plat/sram.h
b/arch/arm/plat-omap/include/plat/sram.h
index 52b9b5c..cc99397 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -27,7 +27,7 @@ extern struct gen_pool *omap_gen_pool;
size_t _sz = size; \
void *_sram = gen_pool_alloc(omap_gen_pool, _sz); \
_res = (_sram ? fncpy(_sram, &(funcp), _sz) : NULL);\
- if (!_res) \
+ if (!_res) \
pr_err("Not enough space in SRAM\n"); \
_res; \
})
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index db486cc..444176e 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -153,7 +153,7 @@ static int __devinit pruss_probe(struct platform_device
*dev)
goto out_free;
}
- gdev->sram_vaddr = (void*)gen_pool_alloc(davinci_gen_pool,
sram_pool_sz);
+ gdev->sram_vaddr = (void *)gen_pool_alloc(davinci_gen_pool,
sram_pool_sz);
if (!gdev->sram_vaddr) {
dev_err(&dev->dev, "Could not allocate SRAM pool\n");
goto out_free;
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
index dd305a2..1c383ab 100644
--- a/sound/soc/davinci/davinci-pcm.c
+++ b/sound/soc/davinci/davinci-pcm.c
@@ -239,7 +239,7 @@ static int allocate_sram(struct snd_pcm_substream
*substream, unsigned size,
return 0;
ppcm->period_bytes_max = size;
- iram_virt = (void*)gen_pool_alloc(davinci_gen_pool, size);
+ iram_virt = (void *)gen_pool_alloc(davinci_gen_pool, size);
if (!iram_virt)
goto exit1;
iram_phys = gen_pool_virt_to_phys(davinci_gen_pool,
--
To unsubscribe from this list: send the line "unsubscribe 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: boot hang using OMAP for-next + Russell's for-linus
Tony Lindgren writes: > * Kevin Hilman [110527 14:24]: >> FYI... I just found this, but won't be able to look into it until next >> week, so if anyone needs a weekend debug project... >> >> Using Tony's for-next branch, I'm able to boot an omap2plus_defconfig (+ >> busybox initramfs) kernel on my 3430/n900 just fine. I then tried to >> merge in Russell's for-linus branch and it hangs during boot. >> >> It appears to hang in the init/registration of i2c busses. Commenting >> out the i2c bus registration from board-rx51-peripherals and disabling a >> few of the users of i2c, I was able to boot. > > Looks like at least v3.0-rc1 boots just fine, so whatever that was > has been already fixed. Indeed, rc1 is booting fine for me now. 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] OMAP: don't trace functions called from sched_clock
Tony Lindgren writes: > * Kevin Hilman [110527 17:28]: >> Kevin Hilman writes: >> >> > Rabin Vincent writes: >> > >> >> omap_readl() is used from the sched_clock() implementations and so must >> >> be marked notrace to avoid recursion in ftrace. Same thing with >> >> mpu_read() for OMAP1. >> >> >> >> Signed-off-by: Rabin Vincent >> > >> > Acked-by: Kevin Hilman >> >> I also meant to suggest this should probably queue for .40-rc series. > > Took a quick look and we should get rid of the omap_readl usage instead > like I commented in another mail. Agreed, that's a better approach. 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 2/2] ARM: OMAP4: MMC: no regulator off during probe for eMMC
On Mon, May 30, 2011 at 7:55 PM, Balaji T K wrote:
> eMMC does not handle power off when not in sleep state,
> Skip regulator disable during probe when eMMC is
> not in known state - state left by bootloader.
>
> Resolves eMMC failure on OMAP4
> mmc0: error -110 whilst initialising MMC card
>
> Signed-off-by: Balaji T K
Tested-by: Kishore Kadiyala
Acked-by: Kishore Kadiyala
> ---
> arch/arm/mach-omap2/board-4430sdp.c | 1 +
> arch/arm/mach-omap2/hsmmc.c | 3 +++
> arch/arm/mach-omap2/hsmmc.h | 1 +
> arch/arm/plat-omap/include/plat/mmc.h | 3 +++
> drivers/mmc/host/omap_hsmmc.c | 3 +++
> 5 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> b/arch/arm/mach-omap2/board-4430sdp.c
> index 73fa90b..b324605 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -322,6 +322,7 @@ static struct omap2_hsmmc_info mmc[] = {
> .gpio_wp = -EINVAL,
> .nonremovable = true,
> .ocr_mask = MMC_VDD_29_30,
> + .no_off_init = true,
> },
> {
> .mmc = 1,
> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
> index 3f8dc16..28ca144 100644
> --- a/arch/arm/mach-omap2/hsmmc.c
> +++ b/arch/arm/mach-omap2/hsmmc.c
> @@ -338,6 +338,9 @@ static int __init omap_hsmmc_pdata_init(struct
> omap2_hsmmc_info *c,
> if (c->no_off)
> mmc->slots[0].no_off = 1;
>
> + if (c->no_off_init)
> + mmc->slots[0].no_regulator_off_init = c->no_off_init;
> +
> if (c->vcc_aux_disable_is_sleep)
> mmc->slots[0].vcc_aux_disable_is_sleep = 1;
>
> diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
> index f119348..f757e78 100644
> --- a/arch/arm/mach-omap2/hsmmc.h
> +++ b/arch/arm/mach-omap2/hsmmc.h
> @@ -18,6 +18,7 @@ struct omap2_hsmmc_info {
> bool nonremovable; /* Nonremovable e.g. eMMC */
> bool power_saving; /* Try to sleep or power off when possible */
> bool no_off; /* power_saving and power is not to go off */
> + bool no_off_init; /* no power off when not in MMC sleep state */
> bool vcc_aux_disable_is_sleep; /* Regulator off remapped to sleep */
> int gpio_cd; /* or -EINVAL */
> int gpio_wp; /* or -EINVAL */
> diff --git a/arch/arm/plat-omap/include/plat/mmc.h
> b/arch/arm/plat-omap/include/plat/mmc.h
> index f38fef9..c7b8741 100644
> --- a/arch/arm/plat-omap/include/plat/mmc.h
> +++ b/arch/arm/plat-omap/include/plat/mmc.h
> @@ -101,6 +101,9 @@ struct omap_mmc_platform_data {
> /* If using power_saving and the MMC power is not to go off */
> unsigned no_off:1;
>
> + /* eMMC does not handle power off when not in sleep state */
> + unsigned no_regulator_off_init:1;
> +
> /* Regulator off remapped to sleep */
> unsigned vcc_aux_disable_is_sleep:1;
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 259ece0..5b2e215 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -435,6 +435,9 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> *host)
> reg = regulator_get(host->dev, "vmmc_aux");
> host->vcc_aux = IS_ERR(reg) ? NULL : reg;
>
> + /* For eMMC do not power off when not in sleep state */
> + if (mmc_slot(host).no_regulator_off_init)
> + return 0;
> /*
> * UGLY HACK: workaround regulator framework bugs.
> * When the bootloader leaves a supply active, it's
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP4: MMC: increase delay for pbias
On Mon, May 30, 2011 at 7:55 PM, Balaji T K wrote: > 4 micro seconds is not enough for PBIAS if MMC regulator is > enabled from MMC regulator OFF. > Increase the delay for PBIAS to stabilize. > Wait for PBIAS and timeout if not. > > Resolves MMC/SD failure on OMAP4 > "Pbias Voltage is not same as LDO" > > Signed-off-by: Balaji T K Acked-by: Kishore Kadiyala -- To unsubscribe from this list: send the line "unsubscribe 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] ARM: OMAP4: MMC: no regulator off during probe for eMMC
* T Krishnamoorthy, Balaji [110531 06:28]:
> On Tue, May 31, 2011 at 6:56 PM, Tony Lindgren wrote:
> > * Balaji T K [110530 07:23]:
> >> eMMC does not handle power off when not in sleep state,
> >> Skip regulator disable during probe when eMMC is
> >> not in known state - state left by bootloader.
> >>
> >> Resolves eMMC failure on OMAP4
> >> mmc0: error -110 whilst initialising MMC card
> >>
> >> --- a/arch/arm/mach-omap2/hsmmc.h
> >> +++ b/arch/arm/mach-omap2/hsmmc.h
> >> @@ -18,6 +18,7 @@ struct omap2_hsmmc_info {
> >> bool nonremovable; /* Nonremovable e.g. eMMC */
> >> bool power_saving; /* Try to sleep or power off when possible */
> >> bool no_off; /* power_saving and power is not to go off */
> >> + bool no_off_init; /* no power off when not in MMC sleep state
> >> */
> >> bool vcc_aux_disable_is_sleep; /* Regulator off remapped to sleep
> >> */
> >> int gpio_cd; /* or -EINVAL */
> >> int gpio_wp; /* or -EINVAL */
> >
> > Can't you use no_off for this too?
>
> no_off is used for devices which do not want to disable regulator at any time.
>
> newly introduced no_off_init is to skip disable regulator only during probe
> After eMMC is put in sleep state (while suspend), regulator for eMMC
> (VAUX1) can be disabled.
OK I'll queue this as a fix too then. Anybody from the MMC list care
to ack?
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 2/2] ARM: OMAP4: MMC: no regulator off during probe for eMMC
On Tue, May 31, 2011 at 6:56 PM, Tony Lindgren wrote:
> * Balaji T K [110530 07:23]:
>> eMMC does not handle power off when not in sleep state,
>> Skip regulator disable during probe when eMMC is
>> not in known state - state left by bootloader.
>>
>> Resolves eMMC failure on OMAP4
>> mmc0: error -110 whilst initialising MMC card
>>
>> --- a/arch/arm/mach-omap2/hsmmc.h
>> +++ b/arch/arm/mach-omap2/hsmmc.h
>> @@ -18,6 +18,7 @@ struct omap2_hsmmc_info {
>> bool nonremovable; /* Nonremovable e.g. eMMC */
>> bool power_saving; /* Try to sleep or power off when possible */
>> bool no_off; /* power_saving and power is not to go off */
>> + bool no_off_init; /* no power off when not in MMC sleep state */
>> bool vcc_aux_disable_is_sleep; /* Regulator off remapped to sleep */
>> int gpio_cd; /* or -EINVAL */
>> int gpio_wp; /* or -EINVAL */
>
> Can't you use no_off for this too?
no_off is used for devices which do not want to disable regulator at any time.
newly introduced no_off_init is to skip disable regulator only during probe
After eMMC is put in sleep state (while suspend), regulator for eMMC
(VAUX1) can be disabled.
--
Thanks and Regards,
Balaji T K
>
> 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 1/2] ARM: OMAP4: MMC: increase delay for pbias
* Balaji T K [110530 07:23]: > 4 micro seconds is not enough for PBIAS if MMC regulator is > enabled from MMC regulator OFF. > Increase the delay for PBIAS to stabilize. > Wait for PBIAS and timeout if not. > > Resolves MMC/SD failure on OMAP4 > "Pbias Voltage is not same as LDO" Thanks will queue as a fix. 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 2/2] ARM: OMAP4: MMC: no regulator off during probe for eMMC
* Balaji T K [110530 07:23]:
> eMMC does not handle power off when not in sleep state,
> Skip regulator disable during probe when eMMC is
> not in known state - state left by bootloader.
>
> Resolves eMMC failure on OMAP4
> mmc0: error -110 whilst initialising MMC card
>
> --- a/arch/arm/mach-omap2/hsmmc.h
> +++ b/arch/arm/mach-omap2/hsmmc.h
> @@ -18,6 +18,7 @@ struct omap2_hsmmc_info {
> boolnonremovable; /* Nonremovable e.g. eMMC */
> boolpower_saving; /* Try to sleep or power off when possible */
> boolno_off; /* power_saving and power is not to go off */
> + boolno_off_init;/* no power off when not in MMC sleep state */
> boolvcc_aux_disable_is_sleep; /* Regulator off remapped to sleep */
> int gpio_cd;/* or -EINVAL */
> int gpio_wp;/* or -EINVAL */
Can't you use no_off for this too?
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 v2] ARM: OMAP2: Add missing include of linux/gpio.h
2011/5/31 Tony Lindgren : > * Axel Lin [110531 05:51]: >> I got some build error like below while executing "make omap2plus_defconfig". >> >> CC arch/arm/mach-omap2/board-2430sdp.o >> arch/arm/mach-omap2/board-2430sdp.c: In function 'omap_2430sdp_init': >> arch/arm/mach-omap2/board-2430sdp.c:247: error: 'GPIOF_OUT_INIT_LOW' >> undeclared (first use in this function) >> arch/arm/mach-omap2/board-2430sdp.c:247: error: (Each undeclared identifier >> is reported only once >> arch/arm/mach-omap2/board-2430sdp.c:247: error: for each function it appears >> in.) >> >> This patch fixes the build error by include linux/gpio.h instead of >> mach/gpio.h. > > Does this happen with next? Yes, I build the kernel with today's linux-next tree. > > Will queue as a fix anyways. Thanks, Axel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU
* Laurent Pinchart [110530 05:43]: > sg_alloc_table can only allocate multi-page scatter-gather list tables > if the architecture supports scatter-gather lists chaining. ARM doesn't > fit in that category. > > The IOMMU driver abuses the sg table structure only to hold page > addresses without ever passing the table to the device. > > Use __sg_alloc_table instead of sg_alloc_table and allocate all entries > in one go. This avoids hitting a BUG_ON in __sg_alloc_table while still > not faking sg list chaining support. Can you please update the patch description with something like "Otherwise foo will happen and bar does not work"? Otherwise these will go into "features that never worked" category for a later merge window. 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 v2] ARM: OMAP2: Add missing include of linux/gpio.h
* Axel Lin [110531 05:51]: > I got some build error like below while executing "make omap2plus_defconfig". > > CC arch/arm/mach-omap2/board-2430sdp.o > arch/arm/mach-omap2/board-2430sdp.c: In function 'omap_2430sdp_init': > arch/arm/mach-omap2/board-2430sdp.c:247: error: 'GPIOF_OUT_INIT_LOW' > undeclared (first use in this function) > arch/arm/mach-omap2/board-2430sdp.c:247: error: (Each undeclared identifier > is reported only once > arch/arm/mach-omap2/board-2430sdp.c:247: error: for each function it appears > in.) > > This patch fixes the build error by include linux/gpio.h instead of > mach/gpio.h. Does this happen with next? Will queue as a fix anyways. 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] Fix: ZOOM: QUART: Request reset GPIO
* Tarun Kanti DebBarma [110520 07:31]: > From: Charulatha V > > Reset GPIO (OMAP_GPIO_152) for QUART in zoom2/zoom3 debug-board is > not requested at all. This would lead to problems if this GPIO is > wrongly requested. Hence request OMAP GPIO 152 for QUART RESET but > do not apply a reset pulse as it would reset QUART and > disturb the QUART settings. Thanks adding to devel-board. 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] omap3evm: add support for nand
* Bryan DE FARIA [110510 04:39]: > This patch adds a basic nand support for the omap3evm. Looks like this needs to be refreshed against v3.0-rc1. 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] OMAP2: CONFIG_TOUCHSCREEN_ADS7846 XOR CONFIG_MTD_NAND_OMAP2 breaks build
* Matthias Scheer [110506 12:09]: > #ifdef clauses in arch/arm/mach-omap2/common-board-devices.h header file broke > kernel build when configured with CONFIG_TOUCHSCREEN_ADS7846 (XOR) > CONFIG_MTD_NAND_OMAP2 > > quick and dirty fix by using #ifdef clauses in the code file, too Care to check if this is still needed for v3.0-rc1? If so, please add proper patch description and Signed-off-by. Thanks, 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 v2] arm: omap3: cm-t35: add support for cm-t3730
* Igor Grinberg [110508 00:17]:
> cm-t3730 is basically the same board as cm-t35, but has DM3730 SoC
> assembled and therefore some changes are required.
> +static void cm_t35_mux_init(void)
> +{
> + int mux_mode = OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT;
> +
> + omap3_mux_init(cm_t35_common_board_mux, OMAP_PACKAGE_CUS);
> +
> + if (cpu_is_omap34xx()) {
> + omap_mux_init_signal("gpio_70", mux_mode);
> + omap_mux_init_signal("gpio_71", mux_mode);
> + omap_mux_init_signal("gpio_72", mux_mode);
> + omap_mux_init_signal("gpio_73", mux_mode);
> + omap_mux_init_signal("gpio_74", mux_mode);
> + omap_mux_init_signal("gpio_75", mux_mode);
> + } else if (cpu_is_omap3630()) {
> + mux_mode = OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT;
> + omap_mux_init_signal("sys_boot0", mux_mode);
> + omap_mux_init_signal("sys_boot1", mux_mode);
> + omap_mux_init_signal("sys_boot3", mux_mode);
> + omap_mux_init_signal("sys_boot4", mux_mode);
> + omap_mux_init_signal("sys_boot5", mux_mode);
> + omap_mux_init_signal("sys_boot6", mux_mode);
> + }
> +
> + omap_mux_init_signal("dss_data18", mux_mode);
> + omap_mux_init_signal("dss_data19", mux_mode);
> + omap_mux_init_signal("dss_data20", mux_mode);
> + omap_mux_init_signal("dss_data21", mux_mode);
> + omap_mux_init_signal("dss_data22", mux_mode);
> + omap_mux_init_signal("dss_data23", mux_mode);
> +}
> +#else
> +static inline void cm_t35_mux_init(void) {}
> #endif
Should this cpu_is_omap if else done once and then set
some data based on it? That would be better if you need to
use it for detection for other things later on as it will
avoid multiple cpu_is/machine_is if else lines of code.
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 v2 1/1] OMAP3: rx-51: Add full regulator definitions
> -Original Message- > From: ext Tony Lindgren [mailto:t...@atomide.com] > Sent: 31. toukokuuta 2011 15:57 > To: Jokiniemi Kalle (Nokia-SD/Tampere) > Cc: broo...@opensource.wolfsonmicro.com; linux-omap@vger.kernel.org; > jhnik...@gmail.com > Subject: Re: [PATCH v2 1/1] OMAP3: rx-51: Add full regulator definitions > > * kalle.jokini...@nokia.com [110512 01:56]: > > Hi Tony, > > > > > -Original Message- > > > From: ext Jarkko Nikula [mailto:jhnik...@gmail.com] > > > Sent: 2. toukokuuta 2011 9:58 > > > To: Jokiniemi Kalle (Nokia-SD/Tampere) > > > Cc: t...@atomide.com; broo...@opensource.wolfsonmicro.com; linux- > > > o...@vger.kernel.org > > > Subject: Re: [PATCH v2 1/1] OMAP3: rx-51: Add full regulator definitions > > > > Did this one get pushed to linux-omap? Just checking on my old patches... > > Adding to devel-board for a future merge window when we can add some > new code. Excellent, thanks. - Kalle > > 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 v2 1/1] OMAP3: rx-51: Add full regulator definitions
* kalle.jokini...@nokia.com [110512 01:56]: > Hi Tony, > > > -Original Message- > > From: ext Jarkko Nikula [mailto:jhnik...@gmail.com] > > Sent: 2. toukokuuta 2011 9:58 > > To: Jokiniemi Kalle (Nokia-SD/Tampere) > > Cc: t...@atomide.com; broo...@opensource.wolfsonmicro.com; linux- > > o...@vger.kernel.org > > Subject: Re: [PATCH v2 1/1] OMAP3: rx-51: Add full regulator definitions > > Did this one get pushed to linux-omap? Just checking on my old patches... Adding to devel-board for a future merge window when we can add some new code. 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
[PATCH v2] ARM: OMAP2: Add missing include of linux/gpio.h
I got some build error like below while executing "make omap2plus_defconfig". CC arch/arm/mach-omap2/board-2430sdp.o arch/arm/mach-omap2/board-2430sdp.c: In function 'omap_2430sdp_init': arch/arm/mach-omap2/board-2430sdp.c:247: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function) arch/arm/mach-omap2/board-2430sdp.c:247: error: (Each undeclared identifier is reported only once arch/arm/mach-omap2/board-2430sdp.c:247: error: for each function it appears in.) This patch fixes the build error by include linux/gpio.h instead of mach/gpio.h. Signed-off-by: Axel Lin Cc: Syed Mohammed Khasim Cc: Tony Lindgren Cc: Grazvydas Ignotas Cc: Steve Sakoman --- arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-apollon.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-overo.c|2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index d54969b..5de6eac 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -26,13 +26,13 @@ #include #include #include +#include #include #include #include #include -#include #include #include #include diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c index f3beb8e..b124bdf 100644 --- a/arch/arm/mach-omap2/board-apollon.c +++ b/arch/arm/mach-omap2/board-apollon.c @@ -27,13 +27,13 @@ #include #include #include +#include #include #include #include #include -#include #include #include #include diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c index 1d10736..5ee034a 100644 --- a/arch/arm/mach-omap2/board-omap3pandora.c +++ b/arch/arm/mach-omap2/board-omap3pandora.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -41,7 +42,6 @@ #include #include -#include #include #include #include diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c index 1555918..9952c20 100644 --- a/arch/arm/mach-omap2/board-overo.c +++ b/arch/arm/mach-omap2/board-overo.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include @@ -45,7 +46,6 @@ #include #include #include -#include #include #include #include -- 1.7.4.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: [PATCHv3] omap: rx51: Platform support for lp5523 led chip
* Ameya Palande [110401 03:13]: Applying this into devel-board for a future merge window after we can add new code with "Platform support for lp5523 led chip" as the patch description. 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: Add missing include of linux/gpio.h
* Axel Lin [110531 05:39]: > I got some build error like below while executing "make omap2plus_defconfig". > > CC arch/arm/mach-omap2/board-2430sdp.o > arch/arm/mach-omap2/board-2430sdp.c: In function 'omap_2430sdp_init': > arch/arm/mach-omap2/board-2430sdp.c:247: error: 'GPIOF_OUT_INIT_LOW' > undeclared (first use in this function) > arch/arm/mach-omap2/board-2430sdp.c:247: error: (Each undeclared identifier > is reported only once > arch/arm/mach-omap2/board-2430sdp.c:247: error: for each function it appears > in.) > make[1]: *** [arch/arm/mach-omap2/board-2430sdp.o] Error 1 > make: *** [arch/arm/mach-omap2] Error 2 > > This patch fixes the build error. Can you please update this to also remove the wrong mach/gpio.h include? Thanks, 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
[PATCH] ARM: OMAP2: Add missing include of linux/gpio.h
I got some build error like below while executing "make omap2plus_defconfig". CC arch/arm/mach-omap2/board-2430sdp.o arch/arm/mach-omap2/board-2430sdp.c: In function 'omap_2430sdp_init': arch/arm/mach-omap2/board-2430sdp.c:247: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function) arch/arm/mach-omap2/board-2430sdp.c:247: error: (Each undeclared identifier is reported only once arch/arm/mach-omap2/board-2430sdp.c:247: error: for each function it appears in.) make[1]: *** [arch/arm/mach-omap2/board-2430sdp.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 This patch fixes the build error. Signed-off-by: Axel Lin Cc: Syed Mohammed Khasim Cc: Tony Lindgren Cc: Grazvydas Ignotas Cc: Steve Sakoman --- arch/arm/mach-omap2/board-2430sdp.c |1 + arch/arm/mach-omap2/board-apollon.c |1 + arch/arm/mach-omap2/board-omap3pandora.c |1 + arch/arm/mach-omap2/board-overo.c|1 + 4 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index d54969b..329b95c 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c index f3beb8e..41f07b0 100644 --- a/arch/arm/mach-omap2/board-apollon.c +++ b/arch/arm/mach-omap2/board-apollon.c @@ -27,6 +27,7 @@ #include #include #include +#include #include #include diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c index 1d10736..89d5fba 100644 --- a/arch/arm/mach-omap2/board-omap3pandora.c +++ b/arch/arm/mach-omap2/board-omap3pandora.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c index 1555918..5942aa5 100644 --- a/arch/arm/mach-omap2/board-overo.c +++ b/arch/arm/mach-omap2/board-overo.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include -- 1.7.4.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] ARM: omap4: Pass core and wakeup mux tables to omap4_mux_init
* Colin Cross [110504 14:54]:
> OMAP4 contains two separate instances of the padconf registers,
> one in the core system config and one in the wakeup system config.
> Pass in two tables to apply the correct values to each instance.
Hmm good catch thanks. Will queue this as a fix.
Tony
> Signed-off-by: Colin Cross
> ---
> arch/arm/mach-omap2/board-4430sdp.c|2 +-
> arch/arm/mach-omap2/board-omap4panda.c |2 +-
> arch/arm/mach-omap2/mux.h |6 --
> arch/arm/mach-omap2/mux44xx.c |5 +++--
> 4 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> b/arch/arm/mach-omap2/board-4430sdp.c
> index 56702c5..41c109a 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -784,7 +784,7 @@ static void __init omap_4430sdp_init(void)
>
> if (omap_rev() == OMAP4430_REV_ES1_0)
> package = OMAP_PACKAGE_CBL;
> - omap4_mux_init(board_mux, package);
> + omap4_mux_init(board_mux, NULL, package);
>
> omap_board_config = sdp4430_config;
> omap_board_config_size = ARRAY_SIZE(sdp4430_config);
> diff --git a/arch/arm/mach-omap2/board-omap4panda.c
> b/arch/arm/mach-omap2/board-omap4panda.c
> index f3a7b10..f70850e 100644
> --- a/arch/arm/mach-omap2/board-omap4panda.c
> +++ b/arch/arm/mach-omap2/board-omap4panda.c
> @@ -720,7 +720,7 @@ static void __init omap4_panda_init(void)
>
> if (omap_rev() == OMAP4430_REV_ES1_0)
> package = OMAP_PACKAGE_CBL;
> - omap4_mux_init(board_mux, package);
> + omap4_mux_init(board_mux, NULL, package);
>
> if (wl12xx_set_platform_data(&omap_panda_wlan_data))
> pr_err("error setting wl12xx data\n");
> diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
> index 137f321..2132308 100644
> --- a/arch/arm/mach-omap2/mux.h
> +++ b/arch/arm/mach-omap2/mux.h
> @@ -323,10 +323,12 @@ int omap3_mux_init(struct omap_board_mux *board_mux,
> int flags);
>
> /**
> * omap4_mux_init() - initialize mux system with board specific set
> - * @board_mux: Board specific mux table
> + * @board_subset:Board specific mux table
> + * @board_wkup_subset: Board specific mux table for wakeup instance
> * @flags: OMAP package type used for the board
> */
> -int omap4_mux_init(struct omap_board_mux *board_mux, int flags);
> +int omap4_mux_init(struct omap_board_mux *board_subset,
> + struct omap_board_mux *board_wkup_subset, int flags);
>
> /**
> * omap_mux_init - private mux init function, do not call
> diff --git a/arch/arm/mach-omap2/mux44xx.c b/arch/arm/mach-omap2/mux44xx.c
> index 9a66445..f5a74da 100644
> --- a/arch/arm/mach-omap2/mux44xx.c
> +++ b/arch/arm/mach-omap2/mux44xx.c
> @@ -1309,7 +1309,8 @@ static struct omap_ball __initdata
> omap4_wkup_cbl_cbs_ball[] = {
> #define omap4_wkup_cbl_cbs_ball NULL
> #endif
>
> -int __init omap4_mux_init(struct omap_board_mux *board_subset, int flags)
> +int __init omap4_mux_init(struct omap_board_mux *board_subset,
> + struct omap_board_mux *board_wkup_subset, int flags)
> {
> struct omap_ball *package_balls_core;
> struct omap_ball *package_balls_wkup = omap4_wkup_cbl_cbs_ball;
> @@ -1347,7 +1348,7 @@ int __init omap4_mux_init(struct omap_board_mux
> *board_subset, int flags)
> OMAP_MUX_GPIO_IN_MODE3,
> OMAP4_CTRL_MODULE_PAD_WKUP_MUX_PBASE,
> OMAP4_CTRL_MODULE_PAD_WKUP_MUX_SIZE,
> - omap4_wkup_muxmodes, NULL, board_subset,
> + omap4_wkup_muxmodes, NULL, board_wkup_subset,
> package_balls_wkup);
>
> return ret;
> --
> 1.7.4.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] ARM: omap4: Enable keypad controller hwmod
* Colin Cross [110504 14:54]:
> The keypad controller hwmod was left commented out, but the
> omap4-keypad driver requires it to function.
I'll queue an earlier patch doing the same thanks.
Regards,
Tony
> Signed-off-by: Colin Cross
> ---
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index abc548a..e1c69ff 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -5109,7 +5109,7 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[]
> = {
> &omap44xx_iva_seq1_hwmod,
>
> /* kbd class */
> -/* &omap44xx_kbd_hwmod, */
> + &omap44xx_kbd_hwmod,
>
> /* mailbox class */
> &omap44xx_mailbox_hwmod,
> --
> 1.7.4.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] omap4: hwmod: Enable the keypad
* Shubhrajyoti [110519 03:43]: > On Thursday 24 February 2011 04:28 PM, Cousson, Benoit wrote: > >On 2/24/2011 6:42 AM, Datta, Shubhrajyoti wrote: > >>From: Shubhrajyoti D > >> > >>Enable the keypad in the hwmod database. > >> > >>Signed-off-by: Shubhrajyoti D > >>Cc: Benoit Cousson > > > >Acked-by: Benoit Cousson > Could this patch be queued for the next merge window. If there are > no further comments. Adding to fixes with the following description: Commit 407a6888f7362cb3dabe69ea6d9dcf3c750dc56a (OMAP4: hwmod data: Add AESS, McPDM, bandgap, counter_32k, MMC, KBD, ISS & IPU) added the entry for keypad, but did not enable it. Enable the keypad in the hwmod database so it works. 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] free rev gpios when they are read, so others can read them later
* Tasslehoff Kjappfot [110528 02:20]:
> Hi Igor.
> >
> > To be consistent with the rest of the file,
> > can the white space here be "tabs" instead of spaces?
> >
> >
> > --
> > Regards,
> > Igor.
> >
>
> They can. New version attached. I'm don't know how to use git send-email to
> continue this thread with a comment to my patch, so it was done manually. Let
> me know if something else is less-than-optimal with my patches. Rookie
> contributor :)
Thanks applying to fixes with following description:
Free Beagle rev gpios when they are read, so others can read them later
Regards,
Tony
> Signed-off-by: Tasslehoff Kjappfot
> ---
> arch/arm/mach-omap2/board-omap3beagle.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
> b/arch/arm/mach-omap2/board-omap3beagle.c
> index 3ff3a2c..54dbb7dd 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -106,6 +106,9 @@ static void __init omap3_beagle_init_rev(void)
> beagle_rev = gpio_get_value(171) | (gpio_get_value(172) << 1)
> | (gpio_get_value(173) << 2);
>
> + gpio_free_array(omap3_beagle_rev_gpios,
> + ARRAY_SIZE(omap3_beagle_rev_gpios));
> +
> switch (beagle_rev) {
> case 7:
> printk(KERN_INFO "OMAP3 Beagle Rev: Ax/Bx\n");
> --
> 1.7.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2: Add missing iounmap in omap4430_phy_init
* Todd Poynor [110526 12:22]:
> !dev case needs iounmap before return.
Adding to fixes thanks.
Tony
> Signed-off-by: Todd Poynor
> ---
> arch/arm/mach-omap2/omap_phy_internal.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
> b/arch/arm/mach-omap2/omap_phy_internal.c
> index ae97336..bd563cf 100644
> --- a/arch/arm/mach-omap2/omap_phy_internal.c
> +++ b/arch/arm/mach-omap2/omap_phy_internal.c
> @@ -56,8 +56,10 @@ int omap4430_phy_init(struct device *dev)
> /* Power down the phy */
> __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
>
> - if (!dev)
> + if (!dev) {
> + iounmap(ctrl_base);
> return 0;
> + }
>
> phyclk = clk_get(dev, "ocp2scp_usb_phy_ick");
> if (IS_ERR(phyclk)) {
> --
> 1.7.3.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] OMAP4: fix return value of omap4_l3_init
* Rabin Vincent [110507 09:54]: > Don't PTR_ERR() a non-error pointer: > > initcall omap4_l3_init+0x0/0xdc returned -544980480 after 0 usecs > initcall omap4_l3_init+0x0/0xdc returned with error code -544980480 Adding to fixes thanks. Tony > Signed-off-by: Rabin Vincent > --- > arch/arm/mach-omap2/devices.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c > index 7b85585..5b8ca68 100644 > --- a/arch/arm/mach-omap2/devices.c > +++ b/arch/arm/mach-omap2/devices.c > @@ -97,7 +97,7 @@ static int __init omap4_l3_init(void) > > WARN(IS_ERR(od), "could not build omap_device for %s\n", oh_name); > > - return PTR_ERR(od); > + return IS_ERR(od) ? PTR_ERR(od) : 0; > } > postcore_initcall(omap4_l3_init); > > -- > 1.7.4.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] OMAP: don't trace functions called from sched_clock
* Kevin Hilman [110527 17:28]: > Kevin Hilman writes: > > > Rabin Vincent writes: > > > >> omap_readl() is used from the sched_clock() implementations and so must > >> be marked notrace to avoid recursion in ftrace. Same thing with > >> mpu_read() for OMAP1. > >> > >> Signed-off-by: Rabin Vincent > > > > Acked-by: Kevin Hilman > > I also meant to suggest this should probably queue for .40-rc series. Took a quick look and we should get rid of the omap_readl usage instead like I commented in another mail. 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] OMAP: don't trace functions called from sched_clock
* Rabin Vincent [110527 08:36]: > Tony, > > On Sun, May 8, 2011 at 14:51, Rabin Vincent wrote: > > omap_readl() is used from the sched_clock() implementations and so must > > be marked notrace to avoid recursion in ftrace. Same thing with > > mpu_read() for OMAP1. We should rather ioremap the 32KSYNCT_BASE in omap_init_clocksource_32k and then use __raw_readl. That allows us to get rid of omap_read usage here and simplifies the code. 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: omap2plus: fix ads7846 pendown gpio request
* Igor Grinberg [110526 06:54]:
> ping
>
> On 05/11/11 10:35, Igor Grinberg wrote:
>
> > Tony,
> >
> >
> > You can fold this one to the original patch from Mike as well,
> >
> > or do you want it into the rc1?
Thanks adding to fixes.
Tony
> >
> >
> >
> > On 05/04/11 20:22, Thomas Weber wrote:
> >
> >> Am 04.05.2011 17:04, schrieb Igor Grinberg:
> >>> introduced by: 96974a24
> >>> (omap: consolidate touch screen initialization among different boards)
> >>>
> >>> ads7846 driver can use either gpio_pendown or get_pendown_state()
> >>> callback. In case of gpio_pendown, it requests the provided gpio_pendown
> >>> thus resulting in double requesting that gpio:
> >>>
> >>> ads7846 spi1.0: failed to request pendown GPIO57
> >>> ads7846: probe of spi1.0 failed with error -16
> >>>
> >>> Fix this by restricting the gpio request to the case of
> >>> get_pendown_state() callback is used.
> >>>
> >>> Signed-off-by: Igor Grinberg
> >>> ---
> >>> arch/arm/mach-omap2/common-board-devices.c | 20 ++--
> >>> 1 files changed, 10 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/common-board-devices.c
> >>> b/arch/arm/mach-omap2/common-board-devices.c
> >>> index d57c71d..61fee80 100644
> >>> --- a/arch/arm/mach-omap2/common-board-devices.c
> >>> +++ b/arch/arm/mach-omap2/common-board-devices.c
> >>> @@ -83,17 +83,17 @@ void __init omap_ads7846_init(int bus_num, int
> >>> gpio_pendown, int gpio_debounce,
> >>> struct spi_board_info *spi_bi =&ads7846_spi_board_info;
> >>> int err;
> >>>
> >>> -err = gpio_request(gpio_pendown, "TS PenDown");
> >>> -if (err) {
> >>> -pr_err("Could not obtain gpio for TS PenDown: %d\n", err);
> >>> -return;
> >>> -}
> >>> -
> >>> -gpio_direction_input(gpio_pendown);
> >>> -gpio_export(gpio_pendown, 0);
> >>> +if (board_pdata&& board_pdata->get_pendown_state) {
> >>> +err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
> >>> +if (err) {
> >>> +pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
> >>> +return;
> >>> +}
> >>> +gpio_export(gpio_pendown, 0);
> >>>
> >>> -if (gpio_debounce)
> >>> -gpio_set_debounce(gpio_pendown, gpio_debounce);
> >>> +if (gpio_debounce)
> >>> +gpio_set_debounce(gpio_pendown, gpio_debounce);
> >>> +}
> >>>
> >>> ads7846_config.gpio_pendown = gpio_pendown;
> >>>
> >> Tested-by: Thomas Weber
> >>
> >> On Devkit8000.
> >>
>
> --
> Regards,
> Igor.
>
--
To unsubscribe from this list: send the line "unsubscribe 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: cm-t3517: fix section mismatch warning
* Igor Grinberg [110516 06:32]:
> ping x3
>
>
> It has been 3 weeks already...
>
>
> On 05/11/11 10:37, Igor Grinberg wrote:
>
> > ping x2
> >
> >
> > Can this one get into .39?
> >
> >
> > On 05/03/11 18:30, Igor Grinberg wrote:
> >
> >> ping!
> >>
> >> Just to make sure you haven't missed this one liner ;)
For the archives, applying into fixes finally.
Regards,
Tony
> >>
> >>
> >> On 04/26/11 23:41, Igor Grinberg wrote:
> >>> WARNING: arch/arm/mach-omap2/built-in.o(.text+0x11014): Section mismatch
> >>> in reference from the function cm_t3517_init_usbh() to the (unknown
> >>> reference) .init.data:(unknown)
> >>> The function cm_t3517_init_usbh() references
> >>> the (unknown reference) __initdata (unknown).
> >>> This is often because cm_t3517_init_usbh lacks a __initdata
> >>> annotation or the annotation of (unknown) is wrong.
> >>>
> >>> Signed-off-by: Igor Grinberg
> >>> ---
> >>> arch/arm/mach-omap2/board-cm-t3517.c |2 +-
> >>> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
> >>> b/arch/arm/mach-omap2/board-cm-t3517.c
> >>> index a27e3ee..802cb60 100644
> >>> --- a/arch/arm/mach-omap2/board-cm-t3517.c
> >>> +++ b/arch/arm/mach-omap2/board-cm-t3517.c
> >>> @@ -178,7 +178,7 @@ static struct usbhs_omap_board_data
> >>> cm_t3517_ehci_pdata __initdata = {
> >>> .reset_gpio_port[2] = -EINVAL,
> >>> };
> >>>
> >>> -static int cm_t3517_init_usbh(void)
> >>> +static int __init cm_t3517_init_usbh(void)
> >>> {
> >>> int err;
> >>>
>
> --
> Regards,
> Igor.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: gpmc-smsc911x: always set irq flags to IORESOURCE_IRQ_LOWLEVEL
* Mike Rapoport [110416 15:20]: > SMSC911x devices attached to OMAP GPMC always use low level irqs. > Setting the appropriate flag in the irq resourse strucure allows using > .flags field in the omap_smsc911x_platform_data for driver specific > flags Looks like this one needs to be refreshed against v3.0-rc1. 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: beagle: Ensure msecure is mux'd to be able to set the RTC
* Alexander Holler [110405 06:38]:
> Without msecure beeing high it isn't possible to set (or start)
> the RTC.
>
> Tested with a BeagleBoard C4.
Adding this into fixes.
Tony
> Signed-off-by: Alexander Holler
> ---
> arch/arm/mach-omap2/board-omap3beagle.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
> b/arch/arm/mach-omap2/board-omap3beagle.c
> index 46d814a..ebe3a7e 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void)
> usb_ehci_init(&ehci_pdata);
> omap3beagle_flash_init();
>
> + /* Ensure msecure is mux'd to be able to set the RTC. */
> + omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
> +
> /* Ensure SDRC pins are mux'd for self-refresh */
> omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
> omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
> --
> 1.7.3.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
--
To unsubscribe from this list: send the line "unsubscribe 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: rtc-twl: catch22 in 2.6.37 and 2.6.38 when clock was never set
* Alexander Holler [110405 03:11]: > Hello, > > Am 04.04.2011 16:29, schrieb Alexander Holler: > > >it just happened here that the rechargeable backup battery for the RTC > >on a TPS65950 run out off power, because of some days while the device > >wasn't powered. > > > >Afterwards I couldn't read or set the clock with hwclock using a kernel > >2.6.37.n or 2.6.38.n. > > > >I don't have a fix, but I think I've analyzed the problem and can offer > >a (bad) workaround. > > > >What happens is the following: > > > >When trying to read or set the clock with hwclock, the driver (rtc-twl) > >starts an alarm, but the irq for the alarm will never get called. The > >result is that a select in hwclock times out (for both operations, read > >or set). > > > >Because I had this clock running before, I've got the idea to try one of > >those old OMAP-kernels (2.6.32-angstrom) using the same userland. > >And with that kernel I could set the clock. > >Using 2.6.37 or 2.6.38 afterwards, hwclock did function again, both read > >an set are working. > > > >So it looks like there is a catch22 in kernels >=2.6.37 (I haven't > >tested .33-.36): > > > >When the clock was never set, the alarm(-irq) doesn't work, so hwclock > >doesn't work, so one can't set the clock. > > It turns out that the missing/wrong initialization of the msecure > line is the problem which disabled setting the clock. After doing > that through a quick hack, I could set the clock. > > I'm using a BeagleBoard C4, but I can't find any msecure > initialization for other boards too. > > What happened with those patches? E.g. those: > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg16125.html Looks like these need reposting. Maybe worth doing generic omap RTC init code though? 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] OMAP4: SRAM: Fix warning: format '%08lx' expects type 'long unsigned int'
* Tony Lindgren [110503 03:52]: > * Russell King - ARM Linux [110428 07:06]: > > > > This looks much better. > > > > Acked-by: Russell King > > > > It looks like Tony hasn't taken it... Tony, are you going to handle > > this patch? > > I can add it into my devel-cleanup branch for next merge window > assuming it won't conflict with your sram changes. If there's a > conflict, then you can take it. > > I'd rather not merge it in the -rc cycle this late as it's not > in the oopses or major regressions category. Got this one finally queued as a fix. 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 v2] OMAP: iovmm: fix SW flags passed by user
* Hiroshi DOYU [110418 00:03]: > From: "ext Ramirez Luna, Omar" > Subject: Re: [PATCH v2] OMAP: iovmm: fix SW flags passed by user > Date: Fri, 15 Apr 2011 10:49:42 -0500 > > > Hi Hiroshi, > > > > On Fri, Mar 25, 2011 at 3:04 PM, Omar Ramirez Luna > > wrote: > >> Commit d038aee24dcd5a2a0d8547f5396f67ae9698ac8e > >> "omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag", > >> changes iovmm to receive flags specified by user, however > >> the upper 16 bits of the flags are wiped by iovmm itself. > >> > >> This fixes IOVMF_DA_FIXED flags from being lost, and lets the user > >> map its desired "device addresses". > >> > >> Signed-off-by: Omar Ramirez Luna > >> --- > >> > >> v2: > >> Include missing reference (commit and name) to patch in > >> description. > > > > If no comments, could you ack this patch? > > Tony, please put this in your queue too. I take that as your ack, will queue into fixes. 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] omap: fix compiler warning
* Michael Jones [110325 09:20]:
> CC arch/arm/plat-omap/gpio.o
> arch/arm/plat-omap/gpio.c: In function ‘omap_gpio_chip_init’:
> arch/arm/plat-omap/gpio.c:1675: warning: unused variable ‘d’
This needs to be refreshed a bit as gpio.c now lives under
drivers. Please also Cc the right mailing lists in addition
to linux-omap, you can get it with:
$ scripts/get_maintainer.pl -f drivers/gpio/gpio-omap.c
Grant Likely (maintainer:GPIO SUBSYSTEM)
linux-ker...@vger.kernel.org (open list)
Regards,
Tony
> Signed-off-by: Michael Jones
> ---
> arch/arm/plat-omap/gpio.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index 971d186..a1d4d1b 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -1672,7 +1672,9 @@ static void __init omap_gpio_chip_init(struct gpio_bank
> *bank)
>
> for (j = bank->virtual_irq_start;
>j < bank->virtual_irq_start + bank_width; j++) {
> +#ifdef CONFIG_LOCKDEP
> struct irq_desc *d = irq_to_desc(j);
> +#endif
>
> lockdep_set_class(&d->lock, &gpio_lock_class);
> set_irq_chip_data(j, bank);
> --
> 1.7.4.1
>
>
> MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
> Registergericht: Amtsgericht Stuttgart, HRB 271090
> Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] omap: rx51: Set regulator V28_A always on
* Jarkko Nikula [110531 01:22]: > The V28_A domain in Nokia N900 that supplies VDD voltages to TLV320AIC34 and > TPA6130A2 should not be shutdown. This is because otherwise there will be > leak from VIO to VDD in TLV320AIC34 and this leak consumes more battery > current that is saved from keeping V28_A off. With this patch the battery > current consumption is approximately 1.5 mA lower. Thanks, applying into fixes. 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] rtc-twl: Switch to using threaded irq
Hi,
I think the patch should also remove the local_irq_enable() call in
twl_rtc_interrupt, since it's no longer needed with threaded irq. At
least on the Pandaboard the RTC is still working with the appended
patch.
-- Sebastian
> >> On Apr 13, 2011 Krishnamoorthy, Balaji T wrote:
> >>> On Wed, Mar 16, 2011 at 9:37 PM, Ilkka Koskinen
> >> wrote:
>
> The driver is accessing to i2c bus in interrupt handler.
> Therefore, it should use threaded irq.
> >>
> >>> Acked-by: Balaji T K
> >>
>
> Signed-off-by: Ilkka Koskinen
> ---
> drivers/rtc/rtc-twl.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
> index ed1b868..2715b96 100644
> --- a/drivers/rtc/rtc-twl.c
> +++ b/drivers/rtc/rtc-twl.c
> @@ -475,7 +475,7 @@ static int __devinit twl_rtc_probe(struct
> platform_device *pdev)
> if (ret < 0)
> goto out1;
>
> - ret = request_irq(irq, twl_rtc_interrupt,
> + ret = request_threaded_irq(irq, NULL, twl_rtc_interrupt,
> IRQF_TRIGGER_RISING,
> dev_name(&rtc->dev), rtc);
> if (ret < 0) {
> --
> 1.7.0.4
--- a/drivers/rtc/rtc-twl.c 2011-05-19 06:06:34.0 +0200
+++ b/drivers/rtc/rtc-twl.c 2011-05-26 20:34:03.0 +0200
@@ -362,14 +362,6 @@
int res;
u8 rd_reg;
-#ifdef CONFIG_LOCKDEP
- /* WORKAROUND for lockdep forcing IRQF_DISABLED on us, which
-* we don't want and can't tolerate. Although it might be
-* friendlier not to borrow this thread context...
-*/
- local_irq_enable();
-#endif
-
res = twl_rtc_read_u8(&rd_reg, REG_RTC_STATUS_REG);
if (res)
goto out;
@@ -462,7 +454,7 @@
if (ret < 0)
goto out1;
- ret = request_irq(irq, twl_rtc_interrupt,
+ ret = request_threaded_irq(irq, NULL, twl_rtc_interrupt,
IRQF_TRIGGER_RISING,
dev_name(&rtc->dev), rtc);
if (ret < 0) {
signature.asc
Description: Digital signature
[PATCHv2 2/2] omap: rx51: Don't power up speaker amplifier at bootup
Speaker amplifier is accidentally powered up in early TWL gpio setup. This
causes a few mA of needless battery current consumption. Without this patch
the amplifier can be shutdown only by having one active audio playback and
shutdown cycle to speaker output.
Thanks to Kalle Jokiniemi for noticing the issue.
Signed-off-by: Jarkko Nikula
Cc: Kalle Jokiniemi
---
v2. Updated on top of commit bc593f5 ("arm: omap2plus: GPIO cleanup").
---
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 02a6587..9903667 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -583,7 +583,7 @@ static int rx51_twlgpio_setup(struct device *dev, unsigned
gpio, unsigned n)
{
/* FIXME this gpio setup is just a placeholder for now */
gpio_request_one(gpio + 6, GPIOF_OUT_INIT_LOW, "backlight_pwm");
- gpio_request_one(gpio + 7, GPIOF_OUT_INIT_HIGH, "speaker_en");
+ gpio_request_one(gpio + 7, GPIOF_OUT_INIT_LOW, "speaker_en");
return 0;
}
--
1.7.4.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
[PATCHv2 1/2] omap: rx51: Set regulator V28_A always on
The V28_A domain in Nokia N900 that supplies VDD voltages to TLV320AIC34 and
TPA6130A2 should not be shutdown. This is because otherwise there will be
leak from VIO to VDD in TLV320AIC34 and this leak consumes more battery
current that is saved from keeping V28_A off. With this patch the battery
current consumption is approximately 1.5 mA lower.
Thanks to Kalle Jokiniemi for noticing the issue.
Signed-off-by: Jarkko Nikula
Cc: Kalle Jokiniemi
---
No changes from v1. Just sent together with 2/2.
---
arch/arm/mach-omap2/board-rx51-peripherals.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index f6247e7..02a6587 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -488,6 +488,7 @@ static struct regulator_init_data rx51_vmmc2 = {
.name = "V28_A",
.min_uV = 280,
.max_uV = 300,
+ .always_on = true, /* due VIO leak to AIC34 VDDs */
.apply_uV = true,
.valid_modes_mask = REGULATOR_MODE_NORMAL
| REGULATOR_MODE_STANDBY,
--
1.7.4.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/RFC 2/4] OMAP2: PM debug: remove register dumping
> Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- > From: Jean Pihet [mailto:jean.pi...@newoldbits.com] > Sent: Monday, May 30, 2011 10:05 AM > To: Hilman, Kevin > Cc: linux-omap@vger.kernel.org; Titiano, Patrick > Subject: Re: [PATCH/RFC 2/4] OMAP2: PM debug: remove register dumping > > On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman wrote: > > Signed-off-by: Kevin Hilman > > --- > > arch/arm/mach-omap2/pm-debug.c | 119 - > --- > > arch/arm/mach-omap2/pm.h |4 - > > arch/arm/mach-omap2/pm24xx.c |6 +- > > 3 files changed, 2 insertions(+), 127 deletions(-) > > > ... > > OK for this change. Is it the intention to use the omapconf tool as > the replacement for the regs dump code? Sorry but omapconf is run from userspace, it cannot be used to dump PRCM registers right before and after MPU WFI. Regards, Patrick. > > Acked-by: Jean Pihet > > Regards, > Jean -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 00/13] OMAP2+: PM: isolate PM code in modules
* jean.pi...@newoldbits.com [110518 10:28]:
> From: Jean Pihet
>
> First attempt at isolation of the OMAP2+ PM code
>
> RFC quality code but successfully tested on board as a proof
> of concept
>
> 1) provide PM functionality as modules
>
> To allow for the PM functionality to be built and used as modules a
> clean-up and isolation task first has been performed ('spaghetti
> unwinding') because there are a lot of cross calls between various parts
> of the PM code (core, platform specific, cpuidle ...).
Glad to see this happening! :)
> 2) Addition of EXPORT_SYMBOL for functions and variables used by
> the code in PM modules. Lots of (too many?) symbols need to exported
> to the PM modules.
Ideally these would all be Linux generic of course..
Anyways, please also consider what all modules could be moved to
live under drivers/pm or similar. I'd assume a lot of this can
be done in a generic way.
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] OMAP4: McBSP: Clear rx_irq at probe time
* Peter Ujfalusi [110518 05:36]: > Hi Tony, > > On Tuesday 17 May 2011 15:57:00 Tony Lindgren wrote: > > This file should be under drivers/ somewhere, can you > > guys please take care of that? > > Do you have a place in mind? How about drivers/mcbsp? > We have several things under arch/arm/plat-omap, like i2c, dma, fb, gpio, > mcbsp, usb... These are all going away into drivers. Only the code to initialize platform dta should be under arch/arm/*omap*/. > Should we create a directory for omap specific drivers under drivers? No, this was discussed few weeks ago on LAKML. The drivers should be grouped by type instead. > For example drivers/omap/ and move the mcbsp there first, without any API > change? This is up to Greg, but I'd assume that a generic framework is the preferred way to go. > If needed we can think of changing the interface within McBSP if it is needed > for other use later. > IMHO invention a common framework (as Jarkko was suggesting) for similar > interfaces need more work, and synchronization between other platforms. Sure, but that's the only option we have to merge any new code. 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] OMAP4: McBSP: Clear rx_irq at probe time
* Jarkko Nikula [110518 00:54]: > On Wed, 18 May 2011 08:52:07 +0300 > Peter Ujfalusi wrote: > > > On Tuesday 17 May 2011 15:57:00 Tony Lindgren wrote: > > > This file should be under drivers/ somewhere, can you > > > guys please take care of that? > > > > Yeah, this has been discussed several times, and we have not reached > > agreement > > where to move this very OMAP specific code. > > One option was to move it under sound/soc/omap/ , since currently the only > > user for mcbsp is audio. > > But McBSP is really versatile beast, it can be used for other things (for > > example it can handle SPI bus as well), so if we move it under ASoC, we are > > going to limit/block other use of these pins. > > We can not just cp arc/arm/plat-omap/mcbsp.c drivers/wherever... > > If we do that, we need to move it under some framework, or create a new one > > (bus driver?), which might be a bit tricky since we have special use of > > McBSP > > from audio side, this does not really fit the bus mode. Other uses of McBSP > > might be happy with the bus driver conversion, but we just do not have > > those. > > > > IMHO the only place we can move this is under sound/soc/omap/ , but who can > > decide, that the McBSP can only be used for audio?? > > > I think we would need some higher level abstraction for this McBSP use > model where the lowest level driver (here OMAP McBSP) is just used to > configure the serial interface and a layer on top of that takes care of > DMA transfer and protocol like SPI, I2S, etc. > > Why higher level abstraction? It's not only OMAP that has a general > purpose serial interface. Also TI DaVinci has similar called McBSP/ASP > and how about other SoCs, probably? What I looked once the DaVinci > McBSP/ASP it wasn't compatible with OMAP McBSP but made me thinking > that if these differences can be handled by a generic API. Yeah I think this is the way to go. 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] arch/arm/mach-omap1/dma.c: Invert calls to platform_device_put and platform_device_del
* Julia Lawall [110513 09:42]:
> From: Julia Lawall
>
> Platform_device_del should be called before platform_device_put, as
> platform_device_put can delete the structure.
>
> Additionally, improve the error handling code for the call to ioremap, so
> that it calls platform_device_put.
>
> The semantic match that finds this problem is:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> expression e1,e2;
> @@
>
> *platform_device_put(e1);
> ... when != e1 = e2
> *platform_device_del(e1);
> //
>
> Signed-off-by: Julia Lawall
Thanks, applying into fixes.
>
> ---
> Is an ioremap needed also? Not clear, because dma_base i a global variable.
I guess you mean iounmap instead of ioremap? In this case we have static
mappings for ioremap, so iounmap is not doing anything. But should be done
for correct handling.
Regards,
Tony
> arch/arm/mach-omap1/dma.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
> index d855934..f5a5220 100644
> --- a/arch/arm/mach-omap1/dma.c
> +++ b/arch/arm/mach-omap1/dma.c
> @@ -284,14 +284,15 @@ static int __init omap1_system_dma_init(void)
> dma_base = ioremap(res[0].start, resource_size(&res[0]));
> if (!dma_base) {
> pr_err("%s: Unable to ioremap\n", __func__);
> - return -ENODEV;
> + ret = -ENODEV;
> + goto exit_device_put;
> }
>
> ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
> if (ret) {
> dev_err(&pdev->dev, "%s: Unable to add resources for %s%d\n",
> __func__, pdev->name, pdev->id);
> - goto exit_device_del;
> + goto exit_device_put;
> }
>
> p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
> @@ -299,7 +300,7 @@ static int __init omap1_system_dma_init(void)
> dev_err(&pdev->dev, "%s: Unable to allocate 'p' for %s\n",
> __func__, pdev->name);
> ret = -ENOMEM;
> - goto exit_device_put;
> + goto exit_device_del;
> }
>
> d = kzalloc(sizeof(struct omap_dma_dev_attr), GFP_KERNEL);
> @@ -380,10 +381,10 @@ exit_release_d:
> kfree(d);
> exit_release_p:
> kfree(p);
> -exit_device_put:
> - platform_device_put(pdev);
> exit_device_del:
> platform_device_del(pdev);
> +exit_device_put:
> + platform_device_put(pdev);
>
> 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
[pm_wip/voltdm_nm][PATCH 2/2] OMAP3+: PM: introduce a central pmic control
Since we are starting to use multiple PMICs in various combinations,
use the existing .omap_chip = OMAP_CHIP_INIT() to mark the
structures we are interested in using per OMAP device we
are currently running on. This mapping is based on the default
device recommendations from TI. Boards using custom PMICs now
have an opportunity to register their own custom mapping.
With this we no longer need omap4_twl_init and omap3_twl_int
instead we introduce a registration mechanism which is PMIC
generic and move twl implementation to use the same.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/omap_pmic.c | 74 +
arch/arm/mach-omap2/omap_twl.c | 87 ---
arch/arm/mach-omap2/pm.c|5 +-
arch/arm/mach-omap2/pm.h| 35 +---
arch/arm/mach-omap2/voltage.h |5 ++
6 files changed, 156 insertions(+), 52 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_pmic.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0a797ec..db5767b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o \
-common.o gpio.o dma.o wd_timer.o
+common.o gpio.o dma.o wd_timer.o omap_pmic.o
omap-2-3-common= irq.o sdrc.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/omap_pmic.c b/arch/arm/mach-omap2/omap_pmic.c
new file mode 100644
index 000..f5567cc
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_pmic.c
@@ -0,0 +1,74 @@
+/*
+ * Registration hooks for PMICs used with OMAP
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon
+ *
+ * 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
+#include
+
+#include "voltage.h"
+
+#include "pm.h"
+
+/**
+ * omap_pmic_init() - trigger point for all PMIC initializers
+ */
+void __init omap_pmic_init(void)
+{
+ omap_twl_init();
+}
+
+/**
+ * omap_pmic_register_data() - Register the PMIC information to OMAP mapping
+ * @omap_pmic__maps: array ending with a empty element representing the maps
+ */
+int __init omap_pmic_register_data(struct omap_pmic_map *omap_pmic_maps)
+{
+ struct voltagedomain *voltdm;
+ struct omap_pmic_map *map;
+ int r;
+
+ if (!omap_pmic_maps)
+ return 0;
+
+ map = omap_pmic_maps;
+
+ while(map->name) {
+ if (!omap_chip_is(map->omap_chip))
+ goto next;
+
+ voltdm = voltdm_lookup(map->name);
+ if (IS_ERR_OR_NULL(voltdm)) {
+ pr_err("%s: unable to find map %s\n",__func__,
+ map->name);
+ goto next;
+ }
+ if (IS_ERR_OR_NULL(map->pmic_data)) {
+ pr_warning("%s: domain[%s] has no pmic data\n",__func__,
+ map->name);
+ goto next;
+ }
+
+ r = omap_voltage_register_pmic(voltdm, map->pmic_data);
+ if (r) {
+ pr_warning("%s: domain[%s] register returned %d\n",
+ __func__, map->name, r);
+ goto next;
+ }
+ if (map->special_action) {
+ r = map->special_action(voltdm);
+ WARN(r, "%s: domain[%s] action returned %d\n", __func__,
+ map->name, r);
+ }
+next:
+ map++;
+ }
+
+ return 0;
+}
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index f474eca..7eb29e9 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -38,11 +38,6 @@
#define OMAP4_VDD_CORE_SR_VOLT_REG 0x61
#define OMAP4_VDD_CORE_SR_CMD_REG 0x62
-#define OMAP4_VP_CONFIG_ERROROFFSET0x00
-#define OMAP4_VP_VSTEPMIN_VSTEPMIN 0x01
-#define OMAP4_VP_VSTEPMAX_VSTEPMAX 0x04
-#define OMAP4_VP_VLIMITTO_TIMEOUT_US 200
-
static bool is_offset_valid;
static u8 smps_offset;
/*
@@ -245,38 +240,9 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.uv_to_vsel = twl6030_uv_to_vsel,
};
-int __init omap4_twl_init(void)
+static int __init twl_set_sr(struct voltagedomain *voltdm)
{
- struct voltagedomain *voltdm;
-
- if (!cpu_is_omap44xx())
- return -ENODEV;
-
- voltdm = voltdm_lookup("mpu");
- omap_voltage_register_pmic(voltdm, &omap4_mpu_pmic);
-
- voltdm = voltdm_lookup("iva");
- omap_voltage_register_pmic(voltdm, &omap4_iva_pmic);
-
-
[pm_wip/voltdm_nm][PATCH 1/2] OMAP3+: PM: VP: use uV for max and min voltage limits
Every PMIC has it's own eccentricities, For example, one of the
PMIC has MSB set to 1 for a specific function - voltage enable!
using an hardcoded value specific for TWL when copied over to
such an implementation causes the system to crash as the MSB bit
was 0 and the voltage got disabled!.
Instead we use actual values and depend on the convertion routines
to abstract out the eccentricities of each PMIC.
With this, we can now move the voltages to a common location in
voltage.h as they are no longer dependent on PMICs and expect the
PMIC's conversion routines to set a cap if the voltage is out of
reach for the PMIC.
Reported-by: Jon Hunter
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap_twl.c | 17 -
arch/arm/mach-omap2/voltage.h | 22 --
arch/arm/mach-omap2/vp.c |4 ++--
3 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 747a810..f474eca 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -30,16 +30,6 @@
#define OMAP3_VP_VSTEPMAX_VSTEPMAX 0x04
#define OMAP3_VP_VLIMITTO_TIMEOUT_US 200
-#define OMAP3430_VP1_VLIMITTO_VDDMIN 0x14
-#define OMAP3430_VP1_VLIMITTO_VDDMAX 0x42
-#define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18
-#define OMAP3430_VP2_VLIMITTO_VDDMAX 0x2c
-
-#define OMAP3630_VP1_VLIMITTO_VDDMIN 0x18
-#define OMAP3630_VP1_VLIMITTO_VDDMAX 0x3c
-#define OMAP3630_VP2_VLIMITTO_VDDMIN 0x18
-#define OMAP3630_VP2_VLIMITTO_VDDMAX 0x30
-
#define OMAP4_SRI2C_SLAVE_ADDR 0x12
#define OMAP4_VDD_MPU_SR_VOLT_REG 0x55
#define OMAP4_VDD_MPU_SR_CMD_REG 0x56
@@ -53,13 +43,6 @@
#define OMAP4_VP_VSTEPMAX_VSTEPMAX 0x04
#define OMAP4_VP_VLIMITTO_TIMEOUT_US 200
-#define OMAP4_VP_MPU_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_MPU_VLIMITTO_VDDMAX 0x39
-#define OMAP4_VP_IVA_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_IVA_VLIMITTO_VDDMAX 0x2D
-#define OMAP4_VP_CORE_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_CORE_VLIMITTO_VDDMAX 0x28
-
static bool is_offset_valid;
static u8 smps_offset;
/*
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index f079167..7366793 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -109,6 +109,24 @@ struct omap_volt_data {
u8 vp_errgain;
};
+/* Min and max voltages from OMAP perspective */
+#define OMAP3430_VP1_VLIMITTO_VDDMIN 85
+#define OMAP3430_VP1_VLIMITTO_VDDMAX 1425000
+#define OMAP3430_VP2_VLIMITTO_VDDMIN 90
+#define OMAP3430_VP2_VLIMITTO_VDDMAX 115
+
+#define OMAP3630_VP1_VLIMITTO_VDDMIN 90
+#define OMAP3630_VP1_VLIMITTO_VDDMAX 135
+#define OMAP3630_VP2_VLIMITTO_VDDMIN 90
+#define OMAP3630_VP2_VLIMITTO_VDDMAX 120
+
+#define OMAP4_VP_MPU_VLIMITTO_VDDMIN 83
+#define OMAP4_VP_MPU_VLIMITTO_VDDMAX 141
+#define OMAP4_VP_IVA_VLIMITTO_VDDMIN 83
+#define OMAP4_VP_IVA_VLIMITTO_VDDMAX 126
+#define OMAP4_VP_CORE_VLIMITTO_VDDMIN 83
+#define OMAP4_VP_CORE_VLIMITTO_VDDMAX 120
+
/**
* struct omap_voltdm_pmic - PMIC specific data required by voltage driver.
* @slew_rate: PMIC slew rate (in uv/us)
@@ -129,8 +147,8 @@ struct omap_voltdm_pmic {
u8 vp_erroroffset;
u8 vp_vstepmin;
u8 vp_vstepmax;
- u8 vp_vddmin;
- u8 vp_vddmax;
+ u32 vp_vddmin;
+ u32 vp_vddmax;
u8 vp_timeout_us;
u8 i2c_slave_addr;
u8 volt_reg_addr;
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index e7d38f6..4b3c1f0 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -64,8 +64,8 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
sys_clk_rate = voltdm->sys_clk.rate / 1000;
timeout = (sys_clk_rate * voltdm->pmic->vp_timeout_us) / 1000;
- vddmin = voltdm->pmic->vp_vddmin;
- vddmax = voltdm->pmic->vp_vddmax;
+ vddmin = voltdm->pmic->uv_to_vsel(voltdm->pmic->vp_vddmin);
+ vddmax = voltdm->pmic->uv_to_vsel(voltdm->pmic->vp_vddmax);
waittime = ((voltdm->pmic->step_size / voltdm->pmic->slew_rate) *
sys_clk_rate) / 1000;
--
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
[pm_wip/voltdm_nm][PATCH 0/2] OMAP3+: PM: Support multiple PMICs
Hi, This series is a precursor to OMAP4460 support which uses 2 PMICs hence requiring a slight reorganization of our data. This subject has been brought up previously in the list as well, this work hopefully will get wider set of platforms to mainline with power management support. The following patches are on top of: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git branch: pm-wip/voltdm_nm NOTE: This probably has a minor conflict with the following applied. http://marc.info/?l=linux-omap&m=130672316613644&w=2 Nishanth Menon (2): OMAP3+: PM: VP: use uV for max and min voltage limits OMAP3+: PM: introduce a central pmic control arch/arm/mach-omap2/Makefile|2 +- arch/arm/mach-omap2/omap_pmic.c | 74 +++ arch/arm/mach-omap2/omap_twl.c | 104 +-- arch/arm/mach-omap2/pm.c|5 +- arch/arm/mach-omap2/pm.h| 35 +++-- arch/arm/mach-omap2/voltage.h | 27 +- arch/arm/mach-omap2/vp.c|4 +- 7 files changed, 178 insertions(+), 73 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_pmic.c 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 2/2] omap: rx51: Don't power up speaker amplifier at bootup
* Jarkko Nikula [110512 04:26]: > Speaker amplifier is accidentally powered up in early TWL gpio setup. This > causes a few mA of needless battery current consumption. Without this patch > the amplifier can be shutdown only by having one active audio playback and > shutdown cycle to speaker output. > > Thanks to Kalle Jokiniemi for noticing the issue. > > Signed-off-by: Jarkko Nikula > Cc: Kalle Jokiniemi > --- > arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c > b/arch/arm/mach-omap2/board-rx51-peripherals.c > index 8242e99..0374562 100644 > --- a/arch/arm/mach-omap2/board-rx51-peripherals.c > +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c > @@ -561,7 +561,7 @@ static int rx51_twlgpio_setup(struct device *dev, > unsigned gpio, unsigned n) > gpio_request(gpio + 6, "backlight_pwm"); > gpio_direction_output(gpio + 6, 0); > gpio_request(gpio + 7, "speaker_en"); > - gpio_direction_output(gpio + 7, 1); > + gpio_direction_output(gpio + 7, 0); > > return 0; > } Jarkko care to rebase this on current -rc1? 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: V 3.0-rc1: [REPORT] OMAP MMC and CONSOLE Regression
On 5/31/2011 12:16 PM, T Krishnamoorthy, Balaji wrote: On Mon, May 30, 2011 at 6:03 PM, Santosh Shilimkar wrote: While trying out V3.0-rc1, I noticed couple of regressions. Am posting this in case anybody come across same issues. 1.OMAP MMC code keep throwing "Pbias Voltage is not same as LDO" error continuously. Balaji is planning post right fix for the same, but just in case you get around this issue, Hi Santosh, You can find MMC pbias fix here http://www.spinics.net/lists/linux-omap/msg51735.html Thanks Balaji. 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
