RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
Serial and gpio clock disabling and gpio_prepare/resume can
be removed
from omap3_pm_idle because they are already done in omap_sram_idle.
And if omap_serial_can_sleep is removed from
omap3_can_sleep it should
be added to omap3_pm_idle.
Omap3_pm_idle can be also put behind #ifndef CONFIG_CPU_IDLE:
+#ifndef CONFIG_CPU_IDLE
static void omap3_pm_idle(void)
{
local_irq_disable();
@@ -454,33 +455,16 @@ static void omap3_pm_idle(void)
if (omap_irq_pending())
goto out;
- omap2_gpio_prepare_for_retention();
-
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(0, 0);
- omap_serial_enable_clocks(0, 1);
- omap_serial_enable_clocks(0, 2);
- /* XXX This is for gpio fclk hack. Will be
removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_disable();
- }
+ if (!omap_serial_can_sleep())
+ goto out;
omap_sram_idle();
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(1, 0);
- omap_serial_enable_clocks(1, 1);
- omap_serial_enable_clocks(1, 2);
- /* XXX This is for gpio fclk hack. Will be
removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_enable();
- }
-
- omap2_gpio_resume_after_retention();
out:
local_fiq_enable();
local_irq_enable();
}
+#endif /* CONFIG_CPU_IDLE */
These are also done as part of the last patch in the series.
Ok.. so I misunderstood your comment initially, I confused omap3_pm_idle with
the
omap3_enter_idle and thought this was already done.
Yes, these can be now removed.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]Enable 4-bit in HSMMC1 and HSMMC2 platform data
From: Madhusudhan Chikkature[EMAIL PROTECTED]
ARM: OMAP3: Enable 4-bit support for HSMMC.
This patch provides the fix to enable 4-bit support for HSMMC.
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
Signed-off-by: purushotam[EMAIL PROTECTED]
---
arch/arm/plat-omap/devices.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
Index: linux-omap-2.6/arch/arm/plat-omap/devices.c
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/devices.c2008-08-07
15:56:52.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/devices.c 2008-08-11 10:57:37.0
+0530
@@ -289,13 +289,17 @@ static void __init omap_init_mmc(void)
mmc = mmc_conf-mmc[0];
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
- if (mmc-enabled)
+ if (mmc-enabled) {
+ mmc1_data.conf = *mmc;
(void) platform_device_register(mmc_omap_device1);
+ }
#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
mmc = mmc_conf-mmc[1];
- if (mmc-enabled)
+ if (mmc-enabled) {
+ mmc2_data.conf = *mmc;
(void) platform_device_register(mmc_omap_device2);
+ }
#endif
return;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP AIC23
- Original Message - From: Hunter, Jon [EMAIL PROTECTED] To: Shekhar, Chandra [EMAIL PROTECTED]; Yuri Jaeger Monti [EMAIL PROTECTED]; linux-omap@vger.kernel.org Sent: Wednesday, August 13, 2008 8:20 AM Subject: RE: OMAP AIC23 Hi Chandra, i have a question, why a client is modifying mcbsp registers. There is a mcbsp config function (omap_mcbsp_config) exported which you can use to configure mcbsp registers. if its an absolute necessity you can use omap_mcbsp_read and omap_mcbsp_write function. which are defined in arch/arm/plat-omap/mcbsp.c. but you need to pass full register name, like OMAP_MCBSP_REG_SPCR1 instead of just SPCR1 ( 'SPCR1' undeclared error). Looking at the source file drivers/i2c/chips/tlv320aic23.c the function omap_mcbsp3_aic23_clock_init() is enabling the McBSP sample rate generator in order to generate the 12MHz system clock to the aic23. I believe that this needs to be done in order to configure the aic23. The good news is that there appears to be a simple fix. All we need to do is move the definitions of the macros OMAP_MCBSP_READ and OMAP_MCBSP_WRITE from mcbsp.c to the header include/asm-arm/arch-omap/mcbsp.h Look like this should be doable. but we will have two read/write defs in header. one will be Macro and other will be function, both mapping to same code. Doing this and making a couple other minor changes I am now able to build the alsa driver successfully for the omap5912 osk. I will submit a patch to the list. Let me know what you think. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
ext Rajendra Nayak [EMAIL PROTECTED] writes:
Check wether serial can sleep is missing from
omap3_enter_idle and it should be removed from omap3_can_sleep:
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index a02da6d..16ff30b 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -431,7 +431,7 @@ static int omap3_enter_idle(struct
cpuidle_device *dev,
current_cx_state = *cx;
- if (cx-type == OMAP3_STATE_C0) {
+ if (cx-type == OMAP3_STATE_C0 || !omap_serial_can_sleep()) {
/* Do nothing for C0, not even a wfi */
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..f9b3676 100644
@@ -391,8 +391,6 @@ int omap3_can_sleep(void)
return 0;
if (atomic_read(sleep_block) 0)
return 0;
- if (!omap_serial_can_sleep())
- return 0;
return 1;
}
Doing this would make serial console to work faster.
Yes, I removed these in my patches and put in the changes suggested by Richard
in 8250.c
I doubt that your changes to 8250.c will be applied. I have understood
that omap specific changes are not accepted to generic 8250
driver. Anyway these changes doesn't help too much. Serial console is
annoyingly slow if sleep while idle is enabled.
I thought the final conclusion of the discussion was that it was too
expensive to the keep the
system in C0 all the time while UART inactivity runs, or did I miss
something?
This was misunderstanding. C0 is selected only for 5 seconds after
last activity on serial console rx line. After this 5 second sleep
prevention, cpuidle continues state selection normally. I don't see
this too expensive, what do you think?
_omap_sram_idle should be non-static:
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..133a666 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -60,7 +60,7 @@ u32 restore_pointer_address;
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
+void (*_omap_sram_idle)(u32 *addr, int save_state);
static void (*saved_idle)(void);
I thought this is already part of the patches. It is now non-static.
Ok, I might have done something wrong with your patches.
Serial and gpio clock disabling and gpio_prepare/resume can
be removed from omap3_pm_idle because they are already done
in omap_sram_idle. And if omap_serial_can_sleep is removed
from omap3_can_sleep it should be added to omap3_pm_idle.
Omap3_pm_idle can be also put behind #ifndef CONFIG_CPU_IDLE:
+#ifndef CONFIG_CPU_IDLE
static void omap3_pm_idle(void)
{
local_irq_disable();
@@ -454,33 +455,16 @@ static void omap3_pm_idle(void)
if (omap_irq_pending())
goto out;
- omap2_gpio_prepare_for_retention();
-
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(0, 0);
- omap_serial_enable_clocks(0, 1);
- omap_serial_enable_clocks(0, 2);
- /* XXX This is for gpio fclk hack. Will be removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_disable();
- }
+ if (!omap_serial_can_sleep())
+ goto out;
omap_sram_idle();
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(1, 0);
- omap_serial_enable_clocks(1, 1);
- omap_serial_enable_clocks(1, 2);
- /* XXX This is for gpio fclk hack. Will be removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_enable();
- }
-
- omap2_gpio_resume_after_retention();
out:
local_fiq_enable();
local_irq_enable();
}
+#endif /* CONFIG_CPU_IDLE */
These are also done as part of the last patch in the series.
I already noticed your second reply.
I would like to see also some reformatting. E.g. patch 11
contains lots of code which is not related to CORE context
save/restore. It might be also good idea to enable only
non-off mode C states and have a pwrdms_setup function which
is something like this:
static int __init pwrdms_setup(struct powerdomain *pwrdm) {
struct power_state *pwrst;
if (!pwrdm-pwrsts)
return 0;
pwrst = kmalloc(sizeof(struct power_state), GFP_KERNEL);
if (!pwrst)
return -ENOMEM;
pwrst-pwrdm = pwrdm;
pwrst-next_state = PWRDM_POWER_RET;
list_add(pwrst-node, pwrst_list);
if (pwrdm_has_hdwr_sar(pwrdm))
pwrdm_enable_hdwr_sar(pwrdm);
#ifdef CONFIG_CPU_IDLE
/* Let cpuidle do selection here */
if (!strcmp(pwrst-pwrdm-name, core_pwrdm) ||
!strcmp(pwrst-pwrdm-name, mpu_pwrdm) ||
[PATCH v2] MUSB: Workaround for simultaneous TX and RX usage
MUSB: Workaround for simultaneous TX and RX usage
MUSB RTL V1.4 has a hardware issue which results in a DMA controller
hang when TX and RX DMA channels are simultaneously enabled. This
affects at least OMAP2430 and OMAP34XX.
Since RX transfers are in Mode 0 and anyway result in one DMA interrupt
per packet, we can use System DMA to unload the RX fifos. MUSB DMA can
be used for all TX channels as before.
Tested with full-duplex TX and RX transfers using g_ether. Runs for 24
hours without a hang. Without this patch, the hang occurs within minutes.
This issue was first reported by Jon Hunter on [1]
[1] http://marc.info/?l=linux-omapm=119634480534453w=2
Signed-off-by: Anand Gadiyar [EMAIL PROTECTED]
---
Patch based on the linux-omap tree. I believe the tabs-to-spaces issue
has been resolved now, but this is the first patch I'm sending out to the
list after that.
Suggestions welcome for removing the 2 #ifdefs below. One suggestion was to
use a module parameter to decide whether to use system dma or mentor dma.
Patch updated with a few ifdefs removed and one compilation break resolved.
drivers/usb/musb/Kconfig |8 ++
drivers/usb/musb/musbhsdma.c | 163 +++
2 files changed, 142 insertions(+), 29 deletions(-)
Index: linux-omap-2.6/drivers/usb/musb/musbhsdma.c
===
--- linux-omap-2.6.orig/drivers/usb/musb/musbhsdma.c2008-07-28
10:54:37.0 +0530
+++ linux-omap-2.6/drivers/usb/musb/musbhsdma.c 2008-08-13 11:58:26.272902373
+0530
@@ -34,6 +34,7 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include musb_core.h
+#include asm/arch/dma.h
#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3430)
#include omap2430.h
@@ -64,6 +65,9 @@
#define MUSB_HSDMA_CHANNELS8
+#define MUSB_FIFO_ADDRESS(epnum) \
+ ((unsigned long) (OMAP_HSOTG_BASE + MUSB_FIFO_OFFSET(epnum)))
+
struct musb_dma_controller;
struct musb_dma_channel {
@@ -75,6 +79,8 @@ struct musb_dma_channel {
u8 bIndex;
u8 epnum;
u8 transmit;
+
+ int sysdma_channel;
};
struct musb_dma_controller {
@@ -93,6 +99,42 @@ static int dma_controller_start(struct d
return 0;
}
+#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_RX
+static void musb_sysdma_completion(int lch, u16 ch_status, void *data)
+{
+ u32 dwAddress;
+ unsigned long flags;
+
+ struct dma_channel *pChannel;
+
+ struct musb_dma_channel *pImplChannel =
+ (struct musb_dma_channel *) data;
+ struct musb_dma_controller *controller = pImplChannel-controller;
+ struct musb *musb = controller-pDmaPrivate;
+ pChannel = pImplChannel-Channel;
+
+ DBG(2, lch = 0x%d, ch_status = 0x%x\n, lch, ch_status);
+ spin_lock_irqsave(musb-lock, flags);
+
+ dwAddress = (u32) omap_get_dma_dst_pos(pImplChannel-sysdma_channel);
+ pChannel-actual_len = dwAddress - pImplChannel-dwStartAddress;
+
+ DBG(2, ch %p, 0x%x - 0x%x (%d / %d) %s\n,
+ pChannel, pImplChannel-dwStartAddress, dwAddress,
+ pChannel-actual_len, pImplChannel-len,
+ (pChannel-actual_len pImplChannel-len) ?
+ = reconfig 0: = complete);
+
+ pChannel-status = MUSB_DMA_STATUS_FREE;
+ musb_dma_completion(musb, pImplChannel-epnum, pImplChannel-transmit);
+
+ spin_unlock_irqrestore(musb-lock, flags);
+ return;
+}
+#else
+#define musb_sysdma_completion NULL
+#endif
+
static void dma_channel_release(struct dma_channel *pChannel);
static int dma_controller_stop(struct dma_controller *c)
@@ -144,6 +186,29 @@ static struct dma_channel *dma_channel_a
/* Tx = mode 1; Rx = mode 0 */
pChannel-desired_mode = transmit;
pChannel-actual_len = 0;
+ pImplChannel-sysdma_channel = -1;
+
+#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_RX
+ if (!transmit) {
+ int ret;
+ ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE,
+ MUSB SysDMA, musb_sysdma_completion,
+ (void *) pImplChannel,
+ (pImplChannel-sysdma_channel));
+
+ if (ret) {
+ printk(KERN_ERR request_dma failed:
+%d\n, ret);
+ controller-bmUsedChannels =
+ ~(1 bBit);
+ pChannel-status =
+ MUSB_DMA_STATUS_UNKNOWN;
+
Re: [PATCH 03/10] OMAP3 SRF: omap3 srf driver
ext Rajendra Nayak [EMAIL PROTECTED] writes:
+int set_pd_latency(struct shared_resource *resp, u32 latency)
+{
+ u32 pd_lat_level, ind, i;
+ struct pd_latency_db *pd_lat_db;
+ struct powerdomain *pwrdm;
+
+ pd_lat_db = resp-resource_data;
+ pwrdm = pd_lat_db-pd;
+ pd_lat_level = PD_LATENCY_OFF;
+ /* using the latency db map to the appropriate PD state */
+ for (ind = 0; ind PD_LATENCY_MAXLEVEL; ind++)
+ if (pd_lat_db-latency[ind] latency)
+ pd_lat_level = ind;
+
+ resp-curr_level = pd_lat_level;
+ switch (pd_lat_level) {
+ case PWRDM_POWER_OFF:
+ case PWRDM_POWER_RET:
+ /* Errata 1.29: No transitions from INACTIVE to RET/OFF
+ * possible.
+ * Need to be taken care of here.
+ */
+ if (pwrdm_read_pwrst(pwrdm) != PWRDM_POWER_ON) {
+ /* Force the clock domains to ON */
+ for (i = 0; pwrdm-pwrdm_clkdms[i]; i++) {
+ omap2_clkdm_deny_idle(pwrdm-pwrdm_clkdms[i]);
+ omap2_clkdm_wakeup(pwrdm-pwrdm_clkdms[i]);
+ }
+ pwrdm_set_next_pwrst(pwrdm, PWRDM_POWER_ON);
+ pwrdm_set_next_pwrst(pwrdm, pd_lat_level);
+ for (i = 0; pwrdm-pwrdm_clkdms[i]; i++) {
+ omap2_clkdm_sleep(pwrdm-pwrdm_clkdms[i]);
+ omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[i]);
+ }
+ } else
+ pwrdm_set_next_pwrst(pwrdm, pd_lat_level);
You could use set_pwrdm_state from pm34xx.c here and update it if
necessary. This way your workaround for errate 1.29 would be available
for cpuidle, pm_idle, srf and suspend.
--
Jouni Högander
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB-webcam support
On Tue, Aug 12, 2008 at 4:45 PM, Syed Mohammed, Khasim [EMAIL PROTECTED] wrote: Hi Arun, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of arun c Sent: Tuesday, August 12, 2008 4:02 PM To: linux-omap@vger.kernel.org Subject: USB-webcam support Hi All, If I have a USB camera with good Linux support, can I connect it to omap3evm(or any omap2) and make it functional? Yes you can, I have tried Logitech LZ708BC on Beagle board and it works good at 160x120 resolution. You just need UVC driver, which I think is part of latest kernel. Is it using USB Isochronous transfer? I checked the web. There is no information regarding the given camera model. Regards, Remith Regards, Khasim http://khasim.blogspot.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP2/3: fix clock/clockdomain bugs
* Paul Walmsley [EMAIL PROTECTED] [080813 00:34]: This series fixes two bugs that cause N800 to panic on boot: - a OMAP2xxx clock code bug, which caused an Unhandled fault: alignment exception (0x001) at 0xc02. panic; and - an OMAP2/3 clockdomain bug, which caused an Unable to handle kernel paging request at virtual address 5f75706d panic. These bugs were exposed by 0e5194e1a84c219bebbb78f305b7a8eabc4a3656 and 718fc6cd4db902aa2242a736cc3feb8744a4c71a. Great, thanks! Pushing today. With the following patches applied on git head, N800 boots fine, but only if CONFIG_DEBUG_LL is enabled. If it is disabled, it hangs at some point in early boot. Don't know why. Maybe it needs flasher --enable-rd-mode --set-rd-flags=serial-console? These patches also boot-tested cleanly on 2430SDP and 3430SDP, both with and without CONFIG_DEBUG_LL. Good Tony textdata bss dec hex filename 3217805 149808 85008 3452621 34aecd vmlinux.n800.orig 3217837 149808 85008 3452653 34aeed vmlinux.n800 arch/arm/mach-omap2/clock24xx.c |2 ++ arch/arm/mach-omap2/clockdomain.c |6 ++ 2 files changed, 8 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git tree updated to v2.6.27-rc2, help needed
On Tue, 12 Aug 2008 17:31:20 +0300 ext Tony Lindgren [EMAIL PROTECTED] wrote: - Alignment error on omap2/3. This seems to happen also with 718fc6cd4db902aa2242a736cc3feb8744a4c71a reverted? - N800 boots up to UI with gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2 and with DEBUG_LL=y. Without DEBUG_LL it hangs somewhere before serial is initialized - With gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-53) there is alignment exception in early booting independently of 718fc6cd4db902aa2242a736cc3feb8744a4c71a Weird that this alignment exception only happens on 24xx, not on 34xx. For me reverting 0e5194e1a84c219bebbb78f305b7a8eabc4a3656 fixes this. Reverting 718fc6cd4db902aa2242a736cc3feb8744a4c71a like Felipe mentioned does not help for me with gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126). I reverted the 0e5194e1a84c219bebbb78f305b7a8eabc4a3656 and now it boots with gcc 4.2.1 but only if DEBUG_LL=y. With gcc 3.4.4 there is no difference. Looks like that alignment is one issue and DEBUG_LL is another? Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git tree updated to v2.6.27-rc2, help needed
* Jarkko Nikula [EMAIL PROTECTED] [080813 10:44]: On Tue, 12 Aug 2008 17:31:20 +0300 ext Tony Lindgren [EMAIL PROTECTED] wrote: - Alignment error on omap2/3. This seems to happen also with 718fc6cd4db902aa2242a736cc3feb8744a4c71a reverted? - N800 boots up to UI with gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2 and with DEBUG_LL=y. Without DEBUG_LL it hangs somewhere before serial is initialized - With gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-53) there is alignment exception in early booting independently of 718fc6cd4db902aa2242a736cc3feb8744a4c71a Weird that this alignment exception only happens on 24xx, not on 34xx. For me reverting 0e5194e1a84c219bebbb78f305b7a8eabc4a3656 fixes this. Reverting 718fc6cd4db902aa2242a736cc3feb8744a4c71a like Felipe mentioned does not help for me with gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126). I reverted the 0e5194e1a84c219bebbb78f305b7a8eabc4a3656 and now it boots with gcc 4.2.1 but only if DEBUG_LL=y. With gcc 3.4.4 there is no difference. Looks like that alignment is one issue and DEBUG_LL is another? Does it behave the same way with Paul's patches? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB-webcam support
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Remith Ravi Sent: Wednesday, August 13, 2008 12:40 PM To: Syed Mohammed, Khasim Cc: arun c; linux-omap@vger.kernel.org Subject: Re: USB-webcam support On Tue, Aug 12, 2008 at 4:45 PM, Syed Mohammed, Khasim [EMAIL PROTECTED] wrote: Hi Arun, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of arun c Sent: Tuesday, August 12, 2008 4:02 PM To: linux-omap@vger.kernel.org Subject: USB-webcam support Hi All, If I have a USB camera with good Linux support, can I connect it to omap3evm(or any omap2) and make it functional? Yes you can, I have tried Logitech LZ708BC on Beagle board and it works good at 160x120 resolution. You just need UVC driver, which I think is part of latest kernel. Is it using USB Isochronous transfer? I checked the web. There is no information regarding the given camera model. It is Logitech V-UAX16, I think the previous one I mentioned was a PID and not the model number. Regards, Khasim -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 04/10] OMAP3 SRF: OMAP PM srf implementation
-Original Message-
From: Högander Jouni [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2008 12:47 PM
To: ext Rajendra Nayak
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 04/10] OMAP3 SRF: OMAP PM srf implementation
Hello Rajendra,
ext Rajendra Nayak [EMAIL PROTECTED] writes:
+/*
+ * Powerdomain usecounting hooks
+ */
+
+void omap_pm_pwrdm_active(struct powerdomain *pwrdm) {
+ char *res_name;
+
+ if (!pwrdm) {
+ WARN_ON(1);
+ return;
+ };
+
+ if (!strcmp(pwrdm-name, wkup_pwrdm) ||
+!strcmp(pwrdm-name, core_pwrdm))
+ return;
+
+ pr_debug(OMAP PM: powerdomain %s is becoming active\n,
+pwrdm-name);
+
+ res_name = get_lat_res_name(pwrdm-name);
+ /* Request for a zero latency which puts the Power
Domain in ON state*/
+ resource_request(res_name, omap_pm_dev, 0);
+ return;
+}
+
+void omap_pm_pwrdm_inactive(struct powerdomain *pwrdm) {
+ char *res_name;
+
+ if (!pwrdm) {
+ WARN_ON(1);
+ return;
+ };
+
+ if (!strcmp(pwrdm-name, wkup_pwrdm) ||
+ !strcmp(pwrdm-name, core_pwrdm))
+ return;
+
+ pr_debug(OMAP PM: powerdomain %s is becoming inactive\n,
+pwrdm-name);
+
+ res_name = get_lat_res_name(pwrdm-name);
+ /* Release the latency requested */
+ resource_release(res_name, omap_pm_dev);
+ return;
+}
For what these two functions are? Why they are
requesting/releasing resource?
Its needed so that a power domain is turned ON while the first clock node in it
is
requested, and turned OFF while the last clock node is disabled.
+
+/*
+ * Should be called before clk framework since clk fw will call
+ * omap_pm_pwrdm_{in,}active()
+ */
+int __init omap_pm_if_early_init(void) {
+ return 0;
+}
Why clock framework (omap2_clkdm_clk_enable/disable) is
calling omap_pm_pwrdm_{in,}active()? Is it for keeping track
of OFF transitions?
This is for clockdomain layer to indicate that a powerdomain should wake up or
be put to sleep
--
Jouni Högander
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]Add 3430 SDP board level support for HSMMC2
arch/arm/mach-omap2/board-3430sdp.c |4
arch/arm/mach-omap2/hsmmc.c | 185
hsmmc.c is used by Beagle too, yet ...
void __init hsmmc_init(void)
{
omap_set_mmc_info(1, hsmmc_data);
+ omap_set_mmc_info(2, hsmmc2_data);
}
... MMC2 is rarely enabled on Beagle, so this is incorrect.
A better way to do this would be to let the boards say exactly
what the hardware configuration is, rather than requiring all
OMAP3 boards to be set up exactly like the SDP...
- Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] OMAP3 SRF: OMAP PM srf implementation
ext Rajendra Nayak [EMAIL PROTECTED] writes:
-Original Message-
From: Högander Jouni [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2008 12:47 PM
To: ext Rajendra Nayak
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 04/10] OMAP3 SRF: OMAP PM srf implementation
Hello Rajendra,
ext Rajendra Nayak [EMAIL PROTECTED] writes:
+/*
+ * Powerdomain usecounting hooks
+ */
+
+void omap_pm_pwrdm_active(struct powerdomain *pwrdm) {
+ char *res_name;
+
+ if (!pwrdm) {
+ WARN_ON(1);
+ return;
+ };
+
+ if (!strcmp(pwrdm-name, wkup_pwrdm) ||
+ !strcmp(pwrdm-name, core_pwrdm))
+ return;
+
+ pr_debug(OMAP PM: powerdomain %s is becoming active\n,
+pwrdm-name);
+
+ res_name = get_lat_res_name(pwrdm-name);
+ /* Request for a zero latency which puts the Power
Domain in ON state*/
+ resource_request(res_name, omap_pm_dev, 0);
+ return;
+}
+
+void omap_pm_pwrdm_inactive(struct powerdomain *pwrdm) {
+ char *res_name;
+
+ if (!pwrdm) {
+ WARN_ON(1);
+ return;
+ };
+
+ if (!strcmp(pwrdm-name, wkup_pwrdm) ||
+ !strcmp(pwrdm-name, core_pwrdm))
+ return;
+
+ pr_debug(OMAP PM: powerdomain %s is becoming inactive\n,
+ pwrdm-name);
+
+ res_name = get_lat_res_name(pwrdm-name);
+ /* Release the latency requested */
+ resource_release(res_name, omap_pm_dev);
+ return;
+}
For what these two functions are? Why they are
requesting/releasing resource?
Its needed so that a power domain is turned ON while the first clock node in
it is
requested, and turned OFF while the last clock node is disabled.
Isn't this already taken care by clock framework? If not I think it
should be. I mean directly requesting domain to wakeup rather than
requesting resource which causes it to wakeup.
Paul, Any comment on this?
+
+/*
+ * Should be called before clk framework since clk fw will call
+ * omap_pm_pwrdm_{in,}active()
+ */
+int __init omap_pm_if_early_init(void) {
+ return 0;
+}
Why clock framework (omap2_clkdm_clk_enable/disable) is
calling omap_pm_pwrdm_{in,}active()? Is it for keeping track
of OFF transitions?
This is for clockdomain layer to indicate that a powerdomain should
wake up or be put to sleep
Same comment as above.
--
Jouni Högander
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]Add 3430 SDP board level support for HSMMC2
- Original Message -
From: David Brownell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: linux-omap@vger.kernel.org
Sent: Wednesday, August 13, 2008 2:24 PM
Subject: Re: [PATCH]Add 3430 SDP board level support for HSMMC2
arch/arm/mach-omap2/board-3430sdp.c |4
arch/arm/mach-omap2/hsmmc.c | 185
hsmmc.c is used by Beagle too, yet ...
void __init hsmmc_init(void)
{
omap_set_mmc_info(1, hsmmc_data);
+ omap_set_mmc_info(2, hsmmc2_data);
}
... MMC2 is rarely enabled on Beagle, so this is incorrect.
There is an another level of abstraction at the board level files like
board-3430sdp.c,board-omap3beagle.c, board-omap3evm.c..
I see that the beagle board file does not enable hsmmc2. So the platform device
for the second controller is not registered anyway.
A better way to do this would be to let the boards say exactly
what the hardware configuration is, rather than requiring all
OMAP3 boards to be set up exactly like the SDP...
I think the initial version was written specific to SDP. Later on it was
changed to hsmmc.c and the platforms
which required simillar setup as SDP started using it. Now, if support for a
new board is required which is unlike SDP a
new file can still be added for that perticular board, right?
Regards,
Madhu
- Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
Doing this would make serial console to work faster.
Yes, I removed these in my patches and put in the changes suggested by
Richard
in 8250.c
I doubt that your changes to 8250.c will be applied. I have understood
that omap specific changes are not accepted to generic 8250
driver. Anyway these changes doesn't help too much. Serial console is
annoyingly slow if sleep while idle is enabled.
Rajendra is it slow in your current builds on this tree with fixes in place?
Sluggish serial has NOT been an issue for us in other trees for a long time.
Perhaps something is missing.
In general keeping code out of the C0 path is good. What ever method makes
console serial usable and gets out of the way fastest to get better power
measurements in typical test environment is good.
Is the comment on the smart idle / no idle aspect or the whole path?
It probably is easier to put changes in our local cpu_idle-C0 function as
compared to a shared 8250 driver. But if it means adding extra code on a hot
system path it is less appealing.
If it's working here, we can ask what opinions are on ARM-Linux list. Today
there are other UART instance specific work arounds in that code.
Regards,
Richard W.
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
getnstimeofday() and suspend
Hi, I noticed an interesting feature in the getnstimeofday() function when used with suspend. System clock is effectively reset to the value it was just before suspend. You can see this behavior e.g. with this command line: date echo mem /sys/power/state date With approx. 2 minutes in suspend state the output for me was this: / # date echo mem sys/power/state date Thu Jan 1 00:13:40 UTC 1970PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) Successfully put all powerdomains to target state Restarting tasks ... done. Thu Jan 1 00:13:42 UTC 1970 I.e., the calendar clock was only advanced 2 seconds. The time you spend in suspend does not matter, the end result is the same, it will reset the time to the value it was before suspend. Is this behavior intended? -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
Hi Richard, ext Woodruff, Richard [EMAIL PROTECTED] writes: Doing this would make serial console to work faster. Yes, I removed these in my patches and put in the changes suggested by Richard in 8250.c I doubt that your changes to 8250.c will be applied. I have understood that omap specific changes are not accepted to generic 8250 driver. Anyway these changes doesn't help too much. Serial console is annoyingly slow if sleep while idle is enabled. Rajendra is it slow in your current builds on this tree with fixes in place? Sluggish serial has NOT been an issue for us in other trees for a long time. Perhaps something is missing. Why this is not problem in your trees is probably because you have similiar hack in place. At least in your CDP tree you have 6 second timeout after activity in serial console. While this timeout is on only mpu is allowed to enter sleep state. After this timeout C state selection continues normally. I agree that this is slightly better, but still not providing realistic PM for testing. PER and CORE sleep transitions are still prevented. I think we must remember that serial console is a debug interface. If doing some PM testing, it is not too big task to wait for 5 seconds before starting the test/measurement. In general keeping code out of the C0 path is good. What ever method makes console serial usable and gets out of the way fastest to get better power measurements in typical test environment is good. Is the comment on the smart idle / no idle aspect or the whole path? My comment was on the changes made to 8250 driver (smart idle / no idle). It probably is easier to put changes in our local cpu_idle-C0 function as compared to a shared 8250 driver. But if it means adding extra code on a hot system path it is less appealing. If it's working here, we can ask what opinions are on ARM-Linux list. Today there are other UART instance specific work arounds in that code. Ok, it would be great to get such code to 8250 driver. Regards, Richard W. -- Jouni Högander -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP3 timer: switch Beagle clockevents source to GPTIMER12
* Paul Walmsley [EMAIL PROTECTED] [080812 02:38]: This patch series allows the clockevents source GPTIMER to be selectable via Kconfig, and changes the Beagle Kbuild config to use GPTIMER12 instead of GPTIMER1. The theory here is that GPTIMER12 has its own internal 32kHz secure oscillator, and does not depend on the external 32kHz clock source, which we suspect may be noisy. Pushing these today. Tony --- size: textdata bss dec hex filename 3265520 145472 105480 3516472 35a838 vmlinux.beagle.orig 3265568 145472 105480 3516520 35a868 vmlinux.beagle arch/arm/configs/omap3_beagle_defconfig |5 +++-- arch/arm/mach-omap2/Kconfig | 16 arch/arm/mach-omap2/timer-gp.c |5 - 3 files changed, 23 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP AIC23
Look like this should be doable. but we will have two read/write defs in header. one will be Macro and other will be function, both mapping to same code. Correct. As well as moving the macro definition, I did add a prototype for the read and write function to the header too. Check out the patch I submitted. Compiling fine now for me. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP5912: Fix omap5912 osk alsa driver [2/2]
* Hunter, Jon [EMAIL PROTECTED] [080813 06:08]: Corrected header file path in file sound/arm/omap/omap-alsa-dma.c. Thanks, pushing today. Tony Signed-off-by: Jon Hunter [EMAIL PROTECTED] --- sound/arm/omap/omap-alsa-dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/arm/omap/omap-alsa-dma.c b/sound/arm/omap/omap-alsa-dma.c index d263933..baafacf 100644 --- a/sound/arm/omap/omap-alsa-dma.c +++ b/sound/arm/omap/omap-alsa-dma.c @@ -64,9 +64,9 @@ #include linux/dma-mapping.h #include linux/io.h #include linux/uaccess.h +#include linux/semaphore.h #include asm/hardware.h -#include asm/semaphore.h #include asm/arch/dma.h #include asm/arch/mcbsp.h #include asm/arch/omap-alsa.h -- 1.4.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getnstimeofday() and suspend
* [EMAIL PROTECTED] [EMAIL PROTECTED] [080813 15:59]: Hi, I noticed an interesting feature in the getnstimeofday() function when used with suspend. System clock is effectively reset to the value it was just before suspend. You can see this behavior e.g. with this command line: date echo mem /sys/power/state date With approx. 2 minutes in suspend state the output for me was this: / # date echo mem sys/power/state date Thu Jan 1 00:13:40 UTC 1970PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) Successfully put all powerdomains to target state Restarting tasks ... done. Thu Jan 1 00:13:42 UTC 1970 I.e., the calendar clock was only advanced 2 seconds. The time you spend in suspend does not matter, the end result is the same, it will reset the time to the value it was before suspend. Is this behavior intended? Hmm, well it should get the value straight from the 32KiHZ sync timer. Does that get stopped somehow during suspend? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP2EVM: Add twl4030 keypad support
* arun c [EMAIL PROTECTED] [080812 11:54]: Hi all, The following set of patches adds twl4030 keypad support for omap2evm. Pushing both today. Tony Regards, Arun C -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Git tree updated to v2.6.27-rc2, help needed
I was able to resolve the build errors, but the kernel doesn't boot beyond this point: Uncompressing Linux... done, booting the kernel. 5Linux version 2.6.27-rc2-omap1-04806-g1edabb5 ([EMAIL PROTECTED]) (gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126)) #2 Wed Aug 13 19:12:34 IST 2008 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f Machine: OMAP3 EVM Memory policy: ECC disabled, Data cache writeback ... trying to debug without much luck so far. Best regards, Sanjeev -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Premi, Sanjeev Sent: Tuesday, August 12, 2008 8:42 PM To: Tony Lindgren; linux-omap@vger.kernel.org; Sakari Ailus; Hiroshi DOYU; Eduardo Valentin Subject: RE: Git tree updated to v2.6.27-rc2, help needed The omap3_evm_defconfig needs to be updated. Else, build fails with: LD init/built-in.o LD .tmp_vmlinux1 arm-none-linux-gnueabi-ld: no machine record defined arm-none-linux-gnueabi-ld: no machine record defined make: *** [.tmp_vmlinux1] Error 1 make oldconfig did not help either. I 'hacked' a defconfig with using omap_3430sdp_defconfig as reference for the build to be successful. Will need to review it later in the night before I send a patch... Best regards, Sanjeev -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Lindgren Sent: Monday, August 11, 2008 8:56 PM To: linux-omap@vger.kernel.org; Sakari Ailus; Hiroshi DOYU; Eduardo Valentin Subject: Git tree updated to v2.6.27-rc2, help needed Hi all, I've updated our git tree to v2.6.27-rc2, and looks like we still have a bunch of issues to solve: - DSP compile is broken as now device_create() is same as device_create_drvdata(). So device_create() expects some some drvdata to be set also in drivers/dsp/dspgateway/task.c and drivers/dsp/dspgateway/dsp_ctl_core.c. Hiroshi, care to take a look at the DSP issue? - V4L drivers init needs to be fixed as the configuration is now passed in some other struct. This affects at least omap24xxcam.c and radio-tea5761.c. Sakari Eduardo, can you look at these issues? - Booting fails early on 3430sdp for some reason - Alignment error on omap2/3. This seems to happen also with 718fc6cd4db902aa2242a736cc3feb8744a4c71a reverted? - Pending patches to isp1301_omap.c need to be tested on H2 and H4 USB - Cpufreq is oopses on at least omap1 I'll continue looking at the 3430sdp boot issues on Tuesday and then update to current mainline with the header changes. Cheers, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: getnstimeofday() and suspend
-Original Message- From: ext Tony Lindgren [mailto:[EMAIL PROTECTED] Sent: 13 August, 2008 17:00 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: getnstimeofday() and suspend * [EMAIL PROTECTED] [EMAIL PROTECTED] [080813 15:59]: Hi, I noticed an interesting feature in the getnstimeofday() function when used with suspend. System clock is effectively reset to the value it was just before suspend. You can see this behavior e.g. with this command line: date echo mem /sys/power/state date With approx. 2 minutes in suspend state the output for me was this: / # date echo mem sys/power/state date Thu Jan 1 00:13:40 UTC 1970PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) Successfully put all powerdomains to target state Restarting tasks ... done. Thu Jan 1 00:13:42 UTC 1970 I.e., the calendar clock was only advanced 2 seconds. The time you spend in suspend does not matter, the end result is the same, it will reset the time to the value it was before suspend. Is this behavior intended? Hmm, well it should get the value straight from the 32KiHZ sync timer. Does that get stopped somehow during suspend? Tony Timer is not stopped, because immediately after suspend I get correct value from it (called from wakeup interrupt), but after this it is reprogrammed by something, or either time management code gets confused somehow. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Updates to omap3_evm_defconfig.
This patch updates the defconfig to 2.6.27-rc2 tag. The updates are based on omap_3430sdp_defconfig. Fixes the build issue reported earlier: LD init/built-in.o LD .tmp_vmlinux1 arm-none-linux-gnueabi-ld: no machine record defined arm-none-linux-gnueabi-ld: no machine record defined make: *** [.tmp_vmlinux1] Error 1 Signed-off-by: Sanjeev Premi [EMAIL PROTECTED] --- arch/arm/configs/omap3_evm_defconfig | 282 ++ 1 files changed, 254 insertions(+), 28 deletions(-) diff --git a/arch/arm/configs/omap3_evm_defconfig b/arch/arm/configs/omap3_evm_defconfig index 718c914..ebeaef3 100644 --- a/arch/arm/configs/omap3_evm_defconfig +++ b/arch/arm/configs/omap3_evm_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.26-rc1-omap1 -# Thu May 8 08:18:45 2008 +# Linux kernel version: 2.6.26-rc7-omap1 +# Tue Aug 12 20:28:50 2008 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -170,15 +170,18 @@ CONFIG_ARCH_OMAP3=y # # OMAP Feature Selections # -CONFIG_OMAP_DEBUG_SRAM_PATCH=y # CONFIG_OMAP_DEBUG_POWERDOMAIN is not set # CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set -# CONFIG_OMAP_RESET_CLOCKS is not set +CONFIG_OMAP_SMARTREFLEX=y +# CONFIG_OMAP_SMARTREFLEX_TESTING is not set +CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_BOOT_TAG=y CONFIG_OMAP_BOOT_REASON=y # CONFIG_OMAP_COMPONENT_VERSION is not set # CONFIG_OMAP_GPIO_SWITCH is not set -# CONFIG_OMAP_MUX is not set +CONFIG_OMAP_MUX=y +# CONFIG_OMAP_MUX_DEBUG is not set +CONFIG_OMAP_MUX_WARNINGS=y # CONFIG_OMAP_MCBSP is not set # CONFIG_OMAP_MMU_FWK is not set # CONFIG_OMAP_MBOX_FWK is not set @@ -189,12 +192,14 @@ CONFIG_OMAP_DM_TIMER=y CONFIG_OMAP_LL_DEBUG_UART1=y # CONFIG_OMAP_LL_DEBUG_UART2 is not set # CONFIG_OMAP_LL_DEBUG_UART3 is not set +CONFIG_OMAP_SERIAL_WAKE=y CONFIG_ARCH_OMAP34XX=y CONFIG_ARCH_OMAP3430=y # # OMAP Board Type # +# CONFIG_MACH_OMAP_LDP is not set # CONFIG_MACH_OMAP_3430SDP is not set CONFIG_MACH_OMAP3EVM=y # CONFIG_MACH_OMAP3_BEAGLE is not set @@ -297,7 +302,7 @@ CONFIG_FPE_NWFPE=y # CONFIG_FPE_FASTFPE is not set CONFIG_VFP=y CONFIG_VFPv3=y -# CONFIG_NEON is not set +CONFIG_NEON=y # # Userspace binary formats @@ -311,7 +316,9 @@ CONFIG_BINFMT_MISC=y # CONFIG_PM=y # CONFIG_PM_DEBUG is not set -# CONFIG_SUSPEND is not set +CONFIG_PM_SLEEP=y +CONFIG_SUSPEND=y +CONFIG_SUSPEND_FREEZER=y # CONFIG_APM_EMULATION is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y @@ -416,16 +423,19 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_CONNECTOR is not set CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set -# CONFIG_MTD_CONCAT is not set -# CONFIG_MTD_PARTITIONS is not set +CONFIG_MTD_CONCAT=y +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_REDBOOT_PARTS is not set +CONFIG_MTD_CMDLINE_PARTS=y +# CONFIG_MTD_AFS_PARTS is not set +# CONFIG_MTD_AR7_PARTS is not set # # User Modules And Translation Layers # -# CONFIG_MTD_CHAR is not set -# CONFIG_MTD_BLKDEVS is not set -# CONFIG_MTD_BLOCK is not set -# CONFIG_MTD_BLOCK_RO is not set +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y # CONFIG_FTL is not set # CONFIG_NFTL is not set # CONFIG_INFTL is not set @@ -436,8 +446,10 @@ CONFIG_MTD=y # # RAM/ROM/Flash chip drivers # -# CONFIG_MTD_CFI is not set +CONFIG_MTD_CFI=y # CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_GEN_PROBE=y +# CONFIG_MTD_CFI_ADV_OPTIONS is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y @@ -448,6 +460,10 @@ CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set +CONFIG_MTD_CFI_INTELEXT=y +# CONFIG_MTD_CFI_AMDSTD is not set +# CONFIG_MTD_CFI_STAA is not set +CONFIG_MTD_CFI_UTIL=y # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set @@ -456,6 +472,9 @@ CONFIG_MTD_CFI_I2=y # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set +# CONFIG_MTD_PHYSMAP is not set +# CONFIG_MTD_ARM_INTEGRATOR is not set +# CONFIG_MTD_OMAP_NOR is not set # CONFIG_MTD_PLATRAM is not set # @@ -481,6 +500,7 @@ CONFIG_MTD_ONENAND_VERIFY_WRITE=y CONFIG_MTD_ONENAND_OMAP2=y # CONFIG_MTD_ONENAND_OTP is not set # CONFIG_MTD_ONENAND_2X_PROGRAM is not set +# CONFIG_MTD_ONENAND_SIM is not set # # UBI - Unsorted block images @@ -492,6 +512,7 @@ CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 @@ -499,6 +520,9 @@ CONFIG_BLK_DEV_RAM_SIZE=16384 # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set # CONFIG_MISC_DEVICES is not set +# CONFIG_EEPROM_93CX6 is not set +# CONFIG_OMAP_STI is not set +# CONFIG_ENCLOSURE_SERVICES is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set @@ -573,8 +597,16 @@ CONFIG_SMC911X=y # # CONFIG_WLAN_PRE80211 is not set #
Re: getnstimeofday() and suspend
I noticed an interesting feature in the getnstimeofday() function when used with suspend. System clock is effectively reset to the value it was just before suspend. ... I.e., the calendar clock was only advanced 2 seconds. The time you spend in suspend does not matter, the end result is the same, it will reset the time to the value it was before suspend. Is this behavior intended? This is why you should configure an RTC to handle RTC_HCTOSYS duties. Like updating the system time from the RTC after resume ... - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] my pending patches
Hi tony, following are my three pending patches since last merge. At least patch #2 for musb should be applied before next merge with mainline. Another version of that patch (without board-file changes) is already in Greg's queue and without this version of that patch in l-o, musb will be broken. It's also a good idea to apply this before you format omap2/3 patches to mainline since I'm getting rid of hdrc_conf.h file, so we don't polute mailine with an extra unused file. ps: I'm on vacations until next week and I don't have devices with me to test them on. The patches were working last time I tried, but after merge I only rebased them and made sure they build. So, please, give it a try before applying. Felipe Balbi (3): input: keypad: General fixes to omap-twl4030keypad.c usb: musb: pass configuration specifics via pdata input: add more error checks to lm8323 driver arch/arm/mach-omap2/board-2430sdp.c |5 +- arch/arm/mach-omap2/board-3430sdp.c |5 +- arch/arm/mach-omap2/board-n800-usb.c| 46 ++- arch/arm/mach-omap2/usb-musb.c | 51 +++- arch/arm/mach-omap2/usb-tusb6010.c |1 - drivers/input/keyboard/lm8323.c | 42 -- drivers/input/keyboard/omap-twl4030keypad.c | 204 --- drivers/usb/musb/musb_core.c| 37 ++--- drivers/usb/musb/musb_core.h| 14 +-- drivers/usb/musb/tusb6010.h | 169 -- include/asm-arm/arch-omap/hdrc_cnf.h| 177 --- include/asm-arm/arch-omap/keypad.h |1 + include/linux/usb/musb.h| 38 +- 13 files changed, 305 insertions(+), 485 deletions(-) delete mode 100644 include/asm-arm/arch-omap/hdrc_cnf.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] input: keypad: General fixes to omap-twl4030keypad.c
The following patch fixes some problems in T2 keypad
driver.
Basically we're passing irq number via platform_data,
moving globals to a structure and fixing a problem
while iterating over the keymap.
It might be that we still have a few locking issues
that might be solved on a later version of this same
patch.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-2430sdp.c |5 +-
arch/arm/mach-omap2/board-3430sdp.c |5 +-
drivers/input/keyboard/omap-twl4030keypad.c | 204 ---
include/asm-arm/arch-omap/keypad.h |1 +
4 files changed, 129 insertions(+), 86 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index b2f8b9c..3270ea6 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -176,9 +176,10 @@ static int sdp2430_keymap[] = {
static struct omap_kp_platform_data sdp2430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp2430_keymap,
- .keymapsize = ARRAY_SIZE(sdp2430_keymap),
+ .keymap = sdp2430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp2430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp2430_kp_device = {
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ee4ec18..94ad839 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -113,9 +113,10 @@ static int sdp3430_keymap[] = {
static struct omap_kp_platform_data sdp3430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp3430_keymap,
- .keymapsize = ARRAY_SIZE(sdp3430_keymap),
+ .keymap = sdp3430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp3430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp3430_kp_device = {
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 68c5b8e..05c7cf8 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -31,6 +31,7 @@
#include linux/types.h
#include linux/input.h
#include linux/kernel.h
+#include linux/mutex.h
#include linux/delay.h
#include linux/bitops.h
#include linux/platform_device.h
@@ -47,52 +48,65 @@
#define KEYNUM_MASK0x00FF
/* Global variables */
-static int *keymap;
-static u16 kp_state[MAX_ROWS];
-static int n_rows, n_cols;
-static struct device *dbg_dev;
-static struct input_dev *omap_twl4030kp;
+struct omap_keypad {
+ int *keymap;
+ unsigned intkeymapsize;
+ u16 kp_state[MAX_ROWS];
+ int n_rows;
+ int n_cols;
+ int irq;
-static int twl4030_kpread(u32 module, u8 *data, u32 reg, u8 num_bytes)
+ struct device *dbg_dev;
+ struct input_dev *omap_twl4030kp;
+
+ /* sync read/write */
+ struct mutexmutex;
+};
+
+static int twl4030_kpread(struct omap_keypad *kp,
+ u32 module, u8 *data, u32 reg, u8 num_bytes)
{
int ret;
ret = twl4030_i2c_read(module, data, reg, num_bytes);
if (ret 0) {
- dev_warn(dbg_dev, Couldn't read TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Couldn't read TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int twl4030_kpwrite_u8(u32 module, u8 data, u32 reg)
+static int twl4030_kpwrite_u8(struct omap_keypad *kp,
+ u32 module, u8 data, u32 reg)
{
int ret;
ret = twl4030_i2c_write_u8(module, data, reg);
if (ret 0) {
- dev_warn(dbg_dev, Could not write TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Could not write TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int omap_kp_find_key(int col, int row)
+static int omap_kp_find_key(struct omap_keypad *kp, int col, int row)
{
int i, rc;
rc = KEY(col, row, 0);
- for (i = 0; keymap[i] != 0; i++)
- if ((keymap[i] ROWCOL_MASK) == rc)
- return keymap[i] KEYNUM_MASK;
+ for (i = 0; i kp-keymapsize; i++)
+ if ((kp-keymap[i] ROWCOL_MASK) == rc)
+ return kp-keymap[i] KEYNUM_MASK;
return -EINVAL;
}
-static inline u16 omap_kp_col_xlate(u8 col)
+static inline u16 omap_kp_col_xlate(struct omap_keypad *kp, u8 col)
{
/* If all bits in a row are active for all coloumns then
* we have that row line connected to gnd. Mark this
@@ -100,30
[PATCH 2/3] usb: musb: pass configuration specifics via pdata
Use platform_data to pass musb configuration-specific
details to musb driver.
It's easier to maintain in the sense that neither board
will affect the other
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-n800-usb.c | 46 +-
arch/arm/mach-omap2/usb-musb.c | 51 +-
arch/arm/mach-omap2/usb-tusb6010.c |1 -
drivers/usb/musb/musb_core.c | 37 +++
drivers/usb/musb/musb_core.h | 14 +---
drivers/usb/musb/tusb6010.h | 169
include/asm-arm/arch-omap/hdrc_cnf.h | 177 --
include/linux/usb/musb.h | 38 +++-
8 files changed, 144 insertions(+), 389 deletions(-)
delete mode 100644 include/asm-arm/arch-omap/hdrc_cnf.h
diff --git a/arch/arm/mach-omap2/board-n800-usb.c
b/arch/arm/mach-omap2/board-n800-usb.c
index 7599f64..16ea8fc 100644
--- a/arch/arm/mach-omap2/board-n800-usb.c
+++ b/arch/arm/mach-omap2/board-n800-usb.c
@@ -35,14 +35,58 @@ static int tusb_set_clock(struct clk *osc_ck, int state);
# define BOARD_MODE MUSB_HOST
#endif
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { ep1_tx, 5,},
+ { ep1_rx, 5,},
+ { ep2_tx, 5,},
+ { ep2_rx, 5,},
+ { ep3_tx, 3,},
+ { ep3_rx, 3,},
+ { ep4_tx, 3,},
+ { ep4_rx, 3,},
+ { ep5_tx, 2,},
+ { ep5_rx, 2,},
+ { ep6_tx, 2,},
+ { ep6_rx, 2,},
+ { ep7_tx, 2,},
+ { ep7_rx, 2,},
+ { ep8_tx, 2,},
+ { ep8_rx, 2,},
+ { ep9_tx, 2,},
+ { ep9_rx, 2,},
+ { ep10_tx, 2, },
+ { ep10_rx, 2, },
+ { ep11_tx, 2, },
+ { ep11_rx, 2, },
+ { ep12_tx, 2, },
+ { ep12_rx, 2, },
+ { ep13_tx, 2, },
+ { ep13_rx, 2, },
+ { ep14_tx, 2, },
+ { ep14_rx, 2, },
+ { ep15_tx, 2, },
+ { ep15_rx, 2, },
+};
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = 1,
+ .dyn_fifo = 1,
+ .soft_con = 1,
+ .dma= 1,
+ .num_eps= 32,
+ .dma_channels = 7,
+ .ram_bits = 12,
+ .eps_bits = musb_eps,
+};
+
static struct musb_hdrc_platform_data tusb_data = {
.mode = BOARD_MODE,
- .multipoint = 1,
.set_power = tusb_set_power,
.set_clock = tusb_set_clock,
.min_power = 25, /* x2 = 50 mA drawn from VBUS as peripheral */
.power = 100, /* Max 100 mA VBUS for host mode */
.clock = osc_ck,
+ .config = musb_config,
};
/*
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index cbd59f8..842edb3 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -37,7 +37,7 @@ static struct resource musb_resources[] = {
: OMAP243X_HS_BASE,
.end= cpu_is_omap34xx()
? OMAP34XX_HSUSB_OTG_BASE + SZ_8K - 1
- : OMAP243X_HS_BASE + SZ_8K -1,
+ : OMAP243X_HS_BASE + SZ_8K - 1,
.flags = IORESOURCE_MEM,
},
[1] = { /* general IRQ */
@@ -73,6 +73,51 @@ static int musb_set_clock(struct clk *clk, int state)
return 0;
}
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { ep1_tx, 10, },
+ { ep1_rx, 10, },
+ { ep2_tx, 9,},
+ { ep2_rx, 9,},
+ { ep3_tx, 3,},
+ { ep3_rx, 3,},
+ { ep4_tx, 3,},
+ { ep4_rx, 3,},
+ { ep5_tx, 3,},
+ { ep5_rx, 3,},
+ { ep6_tx, 3,},
+ { ep6_rx, 3,},
+ { ep7_tx, 3,},
+ { ep7_rx, 3,},
+ { ep8_tx, 2,},
+ { ep8_rx, 2,},
+ { ep9_tx, 2,},
+ { ep9_rx, 2,},
+ { ep10_tx, 2, },
+ { ep10_rx, 2, },
+ { ep11_tx, 2, },
+ { ep11_rx, 2, },
+ { ep12_tx, 2, },
+ { ep12_rx, 2, },
+ { ep13_tx, 2, },
+ { ep13_rx, 2, },
+ { ep14_tx, 2, },
+ { ep14_rx, 2, },
+ { ep15_tx, 2, },
+ { ep15_rx, 2, },
+};
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = 1,
+ .dyn_fifo = 1,
+ .soft_con = 1,
+ .dma= 1,
+ .num_eps= 32,
+ .dma_channels = 7,
+ .dma_req_chan = (1 0) | (1 1) | (1 2) | (1 3),
+ .ram_bits = 12,
+ .eps_bits = musb_eps,
+};
+
[PATCH 3/3] input: add more error checks to lm8323 driver
If we can't reach the driver, we stop trying to probe
it. Useful when building kernel for n800 and n810.
n800 doesn't have lm8323, so that driver shouldn't probe
there.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
drivers/input/keyboard/lm8323.c | 42 +-
1 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 72bb587..3d10a0f 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -348,10 +348,10 @@ static void lm8323_process_error(struct lm8323_chip *lm)
}
}
-static void lm8323_reset(struct lm8323_chip *lm)
+static int lm8323_reset(struct lm8323_chip *lm)
{
/* The docs say we must pass 0xAA as the data byte. */
- lm8323_write(lm, 2, LM8323_CMD_RESET, 0xAA);
+ return lm8323_write(lm, 2, LM8323_CMD_RESET, 0xAA);
}
static int lm8323_configure(struct lm8323_chip *lm)
@@ -360,6 +360,7 @@ static int lm8323_configure(struct lm8323_chip *lm)
int clock = (CLK_SLOWCLKEN | CLK_RCPWM_EXTERNAL);
int debounce = lm-debounce_time 2;
int active = lm-active_time 2;
+ int ret;
/*
* Active time must be greater than the debounce time: if it's
@@ -368,13 +369,25 @@ static int lm8323_configure(struct lm8323_chip *lm)
if (debounce = active)
active = debounce + 3;
- lm8323_write(lm, 2, LM8323_CMD_WRITE_CFG, 0);
- lm8323_write(lm, 2, LM8323_CMD_WRITE_CLOCK, clock);
- lm8323_write(lm, 2, LM8323_CMD_SET_KEY_SIZE, keysize);
+ ret = lm8323_write(lm, 2, LM8323_CMD_WRITE_CFG, 0);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 2, LM8323_CMD_WRITE_CLOCK, clock);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 2, LM8323_CMD_SET_KEY_SIZE, keysize);
+ if (ret)
+ goto err;
lm8323_set_active_time(lm, lm-active_time);
- lm8323_write(lm, 2, LM8323_CMD_SET_DEBOUNCE, debounce);
- lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_STATE, 0xff, 0xff);
- lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_SEL, 0, 0);
+ ret = lm8323_write(lm, 2, LM8323_CMD_SET_DEBOUNCE, debounce);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_STATE, 0xff, 0xff);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_SEL, 0, 0);
+ if (ret)
+ goto err;
/*
* Not much we can do about errors at this point, so just hope
@@ -382,6 +395,11 @@ static int lm8323_configure(struct lm8323_chip *lm)
*/
return 0;
+
+err:
+ dev_err(lm-client-dev, failed to configure lm8323\n);
+
+ return ret;
}
/*
@@ -721,7 +739,9 @@ static int lm8323_probe(struct i2c_client *client,
else if (lm-active_time == -1) /* Disable sleep. */
lm-active_time = 0;
- lm8323_reset(lm);
+ err = lm8323_reset(lm);
+ if (err)
+ goto fail2;
/* Nothing's set up to service the IRQ yet, so just spin for max.
* 100ms until we can configure. */
@@ -738,7 +758,9 @@ static int lm8323_probe(struct i2c_client *client,
msleep(1);
}
- lm8323_configure(lm);
+ err = lm8323_configure(lm);
+ if (err)
+ goto fail2;
/* If a true probe check the device */
if (lm8323_read_id(lm, data) != 0) {
--
1.6.0.rc1.71.gfba5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
-Original Message- From: Woodruff, Richard [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2008 6:06 PM To: Högander Jouni; Nayak, Rajendra Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 Doing this would make serial console to work faster. Yes, I removed these in my patches and put in the changes suggested by Richard in 8250.c I doubt that your changes to 8250.c will be applied. I have understood that omap specific changes are not accepted to generic 8250 driver. Anyway these changes doesn't help too much. Serial console is annoyingly slow if sleep while idle is enabled. Rajendra is it slow in your current builds on this tree with fixes in place? Sluggish serial has NOT been an issue for us in other trees for a long time. Perhaps something is missing. Yes, its indeed a bit sluggish in my builds as well. Not as good as what we have in our internal tree. In general keeping code out of the C0 path is good. What ever method makes console serial usable and gets out of the way fastest to get better power measurements in typical test environment is good. Is the comment on the smart idle / no idle aspect or the whole path? It probably is easier to put changes in our local cpu_idle-C0 function as compared to a shared 8250 driver. But if it means adding extra code on a hot system path it is less appealing. If it's working here, we can ask what opinions are on ARM-Linux list. Today there are other UART instance specific work arounds in that code. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
