Re: [PATCH v2] serial: 8250: add IRQ trigger support
* Vikram Pandita vikram.pand...@ti.com [090623 02:20]:
There is currently no provision for passing IRQ trigger flags for
serial IRQs with triggering requirements (such as GPIO IRQs)
This patch adds irqflags to plat_serial8250_port that can be passed
from board file to reqest_irq() of 8250 driver
Changes are backward compatible with boards passing UPF_SHARE_IRQ flag
How about just fix all the instances of UPF_SHARE_IRQ and make them
use irqflags there are not too many instances of that?
Otherwise we're just piling more hacks to the driver..
Also, the irqflags may need to be initialized in some cases for
struct uart_port, so that should be checked.
Regards,
Tony
Tested on Zoom2 board that has IRQF_TRIGGER_RISING requirement for 8250 irq
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/serial/8250.c | 14 +-
drivers/serial/8250.h |1 +
include/linux/serial_8250.h |1 +
include/linux/serial_core.h |1 +
4 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index bab115e..d18a4c0 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -1674,7 +1674,7 @@ static int serial_link_irq_chain(struct uart_8250_port
*up)
INIT_LIST_HEAD(up-list);
i-head = up-list;
spin_unlock_irq(i-lock);
-
+ irq_flags |= up-port.irqflags;
ret = request_irq(up-port.irq, serial8250_interrupt,
irq_flags, serial, i);
if (ret 0)
@@ -2023,7 +2023,7 @@ static int serial8250_startup(struct uart_port *port)
* allow register changes to become visible.
*/
spin_lock_irqsave(up-port.lock, flags);
- if (up-port.flags UPF_SHARE_IRQ)
+ if (up-port.irqflags IRQF_SHARED)
disable_irq_nosync(up-port.irq);
wait_for_xmitr(up, UART_LSR_THRE);
@@ -2036,7 +2036,7 @@ static int serial8250_startup(struct uart_port *port)
iir = serial_in(up, UART_IIR);
serial_out(up, UART_IER, 0);
- if (up-port.flags UPF_SHARE_IRQ)
+ if (up-port.irqflags IRQF_SHARED)
enable_irq(up-port.irq);
spin_unlock_irqrestore(up-port.lock, flags);
@@ -2681,6 +2681,7 @@ static void __init serial8250_isa_init_ports(void)
i++, up++) {
up-port.iobase = old_serial_port[i].port;
up-port.irq = irq_canonicalize(old_serial_port[i].irq);
+ up-port.irqflags = old_serial_port[i].irqflags;
up-port.uartclk = old_serial_port[i].baud_base * 16;
up-port.flags= old_serial_port[i].flags;
up-port.hub6 = old_serial_port[i].hub6;
@@ -2689,7 +2690,7 @@ static void __init serial8250_isa_init_ports(void)
up-port.regshift = old_serial_port[i].iomem_reg_shift;
set_io_from_upio(up-port);
if (share_irqs)
- up-port.flags |= UPF_SHARE_IRQ;
+ up-port.irqflags |= IRQF_SHARED;
}
}
@@ -2879,6 +2880,7 @@ int __init early_serial_setup(struct uart_port *port)
p-iobase = port-iobase;
p-membase = port-membase;
p-irq = port-irq;
+ p-irqflags = port-irqflags;
p-uartclk = port-uartclk;
p-fifosize = port-fifosize;
p-regshift = port-regshift;
@@ -2952,6 +2954,7 @@ static int __devinit serial8250_probe(struct
platform_device *dev)
port.iobase = p-iobase;
port.membase= p-membase;
port.irq= p-irq;
+ port.irqflags = p-irqflags;
port.uartclk= p-uartclk;
port.regshift = p-regshift;
port.iotype = p-iotype;
@@ -2964,7 +2967,7 @@ static int __devinit serial8250_probe(struct
platform_device *dev)
port.serial_out = p-serial_out;
port.dev= dev-dev;
if (share_irqs)
- port.flags |= UPF_SHARE_IRQ;
+ port.irqflags |= IRQF_SHARED;
ret = serial8250_register_port(port);
if (ret 0) {
dev_err(dev-dev, unable to register port at index %d
@@ -3106,6 +3109,7 @@ int serial8250_register_port(struct uart_port *port)
uart-port.iobase = port-iobase;
uart-port.membase = port-membase;
uart-port.irq = port-irq;
+ uart-port.irqflags = port-irqflags;
uart-port.uartclk = port-uartclk;
uart-port.fifosize = port-fifosize;
uart-port.regshift = port-regshift;
diff --git a/drivers/serial/8250.h
FW: [Help] Does HW flow contorl (auto RTS/CTS) in drivers/serial/8250.c work for OMAP34xx?
Instead of using below code in current drive, it seems we have to add code to follow the steps in OMAP34xx TRM to make it work. /* * TI16C752/Startech hardware flow control. FIXME: * - TI16C752 requires control thresholds to be set. * - UART_MCR_RTS is ineffective if auto-RTS mode is enabled. */ if (termios-c_cflag CRTSCTS) efr |= UART_EFR_CTS; Followings are copied from OMAP34xx TRM. To enable and configure hardware flow control, perform the following procedure: 1. Switch to register configuration mode A to access the UARTi.MCR_REG register: a. Save the current UARTi.LCR_REG. b. Set UARTi.LCR_REG to 0x0080. 2. Enable register submode TCR_TLR to access UARTi.TCR_REG (part 1 of 2): a. Save the UARTi.MCR_REG[6] TCR_TLR value. b. Set UARTi.MCR_REG[6] TCR_TLR = 1. 3. Switch to register configuration mode B to access the UARTi.EFR_REG register: Set UARTi.LCR_REG to 0x00BF. 4. Enable register submode TCR_TLR to access the UARTi.TCR_REG register (part 2 of 2): a. Save the UARTi.EFR_REG[4] ENHANCED_EN value. b. Set the UARTi.EFR_REG[4] ENHANCED_EN bit to 1. 5. Load the new start and halt trigger values for hardware flow control: Set the following bits to the desired values: * UARTi.TCR_REG[7:4] AUTO_RTS_START * UARTi.TCR_REG[3:0] AUTO_RTS_HALT 6. Enable or disable receive and transmit hardware flow control mode and restore the UARTi.EFR_REG[4] ENHANCED_EN value saved in Step 4a. Set the following bits to the desired values: * UARTi.EFR_REG[7] AUTO_CTS_EN (0: Disable/1: Enable) * UARTi.EFR_REG[6] AUTO_RTS_EN (0: Disable/1: Enable) Restore UARTi.EFR_REG[4] ENHANCED_EN to the saved value. 7. Switch to register configuration mode A to access UARTi.MCR_REG: Set UARTi.LCR_REG to 0x0080. 8. Restore the UARTi.MCR_REG[6] TCR_TLR value saved in Step 2a. 9. Restore the UARTi.LCR_REG value saved in Step 1a. See Section 17.4.4.1.3.2, Hardware Flow Control, to choose the following values: * UARTi.EFR_REG[7] AUTO_CTS_EN * UARTi.EFR_REG[6] AUTO_RTS_EN * UARTi.TCR_REG[7:4] AUTO_RTS_START * UARTi.TCR_REG[3:0] AUTO_RTS_HALT -- 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] OMAP3: PM: Remove duplicate code
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com --- arch/arm/mach-omap2/pm34xx.c | 18 -- 1 files changed, 0 insertions(+), 18 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 7a4a525..d45295d 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -913,24 +913,6 @@ static void __init prcm_setup_regs(void) /* Clear any pending PRCM interrupts */ prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); - /* Don't attach IVA interrupts */ - prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL); - prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1); - prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3); - prm_write_mod_reg(0, OMAP3430_PER_MOD, OMAP3430_PM_IVAGRPSEL); - - /* Clear any pending 'reset' flags */ - prm_write_mod_reg(0x, MPU_MOD, RM_RSTST); - prm_write_mod_reg(0x, CORE_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_PER_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_EMU_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_NEON_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_DSS_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430ES2_USBHOST_MOD, RM_RSTST); - - /* Clear any pending PRCM interrupts */ - prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); - omap3_iva_idle(); omap3_d2d_idle(); } -- 1.6.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] OMAP: PM: Correct the use of cpufreq
From: Eero Nurkkala ext-eero.nurkk...@nokia.com Wrong info was used to feed the cpufreq. It is possible now to get below the user defined limit defined at /cpufreq/scaling_min_freq. With this patch, the user defined limits are being obeyed instead of always using the absolute max and min values supported by the device. Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com --- arch/arm/plat-omap/cpu-omap.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c index 843e8af..1868c0d 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -78,10 +78,10 @@ static int omap_target(struct cpufreq_policy *policy, /* Ensure desired rate is within allowed range. Some govenors * (ondemand) will just pass target_freq=0 to get the minimum. */ - if (target_freq policy-cpuinfo.min_freq) - target_freq = policy-cpuinfo.min_freq; - if (target_freq policy-cpuinfo.max_freq) - target_freq = policy-cpuinfo.max_freq; + if (target_freq policy-min) + target_freq = policy-min; + if (target_freq policy-max) + target_freq = policy-max; freqs.old = omap_getspeed(0); freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000; -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon errata 1.153
Kevin,
-Original Message-
From: Kevin Hilman
Sonasath, Moiz m-sonas...@ti.com writes:
This patch includes the workarround for I2C Errata 1.153:
[...]
+static int omap_i2c_wait_for_xudf(struct omap_i2c_dev *dev)
+{
+ u16 xudf;
+ int counter = 500;
+
+ /* We are in interrupt context. Wait for XUDF for max 7 msec */
What does being in interrupt context have to do with how long you
wait? Threaded interrupts are now in mainline and will become the
default, so this ISR may run in thread context.
The interrupt context comment was meant to say that we can't sleep. Perhaps,
with threaded interrupts that might not be true (I am not sure). We can remove
the interrupt context comment.
@@ -647,7 +679,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
while ((stat = (omap_i2c_read_reg(dev,
OMAP_I2C_STAT_REG))) bits) {
dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat);
if (count++ == 100) {
- dev_warn(dev-dev, Too much work in
one IRQ\n);
+ dev_dbg(dev-dev, Too much work in one IRQ\n);
Should stay as dev_warn I think.
When I2C is used to transfer a large number of bytes continuously (e.g. during
some camera sensor firmware update), we hit the max count more often now
(because of the delay introduced by the workaround implementation). In this
case, its undesirable to see the dev_warn messages fill up the console.
Changing this to dev_dbg means that this message is not printed in the expected
case.
Regards,
Nishant
--
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][OMAP3:I2C]Workaround for OMAP3430 I2C silicon errata 1.153
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kamat, Nishant
Sent: Tuesday, June 23, 2009 12:55 PM
@@ -647,7 +679,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
while ((stat = (omap_i2c_read_reg(dev,
OMAP_I2C_STAT_REG))) bits) {
dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat);
if (count++ == 100) {
- dev_warn(dev-dev, Too much work in
one IRQ\n);
+ dev_dbg(dev-dev, Too much work in one IRQ\n);
Should stay as dev_warn I think.
When I2C is used to transfer a large number of bytes continuously (e.g.
during some camera sensor firmware update), we hit the max count more
often now (because of the delay introduced by the workaround
implementation). In this case, its undesirable to see the dev_warn
messages fill up the console. Changing this to dev_dbg means that this
message is not printed in the expected case.
Just wondering on this - cant I do a multibyte write upto 255 bytes? Is
count==100 not enough given that we used buffered writes? The real question is
this:
Are devices expected to trigger retry logic to the extent where the error
condition is triggered?
I think this might be an indication of something else being at fault with the
sensor /configuration of sensor - hiding the error messages by moving warn-dbg
is not correct IMHO.
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: Please help in adding ams-delta support to ASoC
Hi, Arun K S wrote: On Fri, Jun 19, 2009 at 4:20 AM, Janusz Krzysztofikjkrzy...@tis.icnet.pl wrote: After all, could someone please give me an advise, what tree, even with buggy omap1510 mcbsp/dsp support, should I base my work on for best results? You have to use current omap tree with the patches from current sound tree(ASoC omap platform drivers changes) for testing the driver. Arun, Thanks, from now on I use l-o master, right? As I do my development using OE, I am still investigating how to set up a bb recipe to get ALSA git tree applied over l-o. Arun K S wrote: On Fri, Jun 19, 2009 at 4:20 AM, Janusz Krzysztofikjkrzy...@tis.icnet.pl wrote: Arun K S wrote: On Thu, Jun 18, 2009 at 4:40 AM, Janusz Krzysztofikjkrzy...@tis.icnet.pl wrote: ... I retried the new driver on commit 90e758af52ba803cba233fabee81176d99589f09 and confirmed the prevoiusly seen hangup. I found that it was omap_mcbsp_request() never returning back from. I faced the same issue while writing ASoC driver for tlv320aic23b codec. You can have a look at this thread: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg03852.html Initially i used to add the omap_mcbsp_request() at the boot time, other wise it hangs up. ... I believe there are some patches from Russel for the DSP memory mapping during 2.6.29 kernel. Jarkko Nikula wrote: On Thu, 18 Jun 2009 13:40:56 +0200 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: Then I retired the same on the commit d8376cc482b241701f7606c81ad578b90853e175 and got similiar hangup. Can you move this boot time initialization moment around with xxx_initcall variants to see what is the point where block is not anymore accessable? Basically around the DSP power up and idle code (were there such code for older audio drivers?) and where unused clocks are disabled (functions clk_disable_unused and omap1_clk_disable_unused). Arun, Jarkko, Thanks. Fortunatelly, I can confirm that the problem of omap_mcbsp_request() not returning back when called too late, has been already solved and no longer applies to 2.6.30, be it omap or mainline, with or without a working dsp. Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [090618 14:52]: Tony Lindgren wrote: * Peter Ujfalusi peter.ujfal...@nokia.com [090618 12:03]: On Wednesday 17 June 2009 17:12:38 ext Janusz Krzysztofik wrote: Janusz Krzysztofik wrote: ... got the answer from omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0x. So it looks like I simply get no acccess to mcbsp1 at all. One thing that I have noticed is that the McBSP1 (and 3) is under the DSP Public Peripherals, while McBSP2 is under MPU Public Peripherals (in OMAP1510). On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up. AFAICS there is no DSP code in mainline at all, so the answer is no, DSP was likely not powered up at all. We at least used to have code to power and idle the DSP even without the dspgateway compiled in.. Sorry I don't remember the details. But most likely you need to have the dspgateway patch enabled. I hacked in the prevoiusly removed dsp_common.c containing omap_dsp_init(), with all header files required for successfull compilation, and finally got my driver working on top of current l-o. Jarkko, Peter, Mark, Tony, Arun, Thanks for your help. It seams that dsp_common.c with its omap_dsp_init() used to be always compiled into the kernel, even if the rest of dspgateway code was not compiled or compiled as a module. This file, initially existing in arch/arm/plat-omap, was moved to drivers/dsp (commit 23ed8b5cf043a9cd40b5d415645b3543357d9a1a), and then removed completely (commit 2512fd29db4eb09e82d182596304c7aaf76d2c5c), together with other dspgateway code. Since then, McBSP ports that are DSP public peripherals have probably no chance to work, at least on omap1510, as I have verified. Perhaps this single file (or its part with omap_dsp_init() at least) should never happen to be moved out of arch/arm/plat-omap? One of its related header files, dsp_common.h, has survived in the tree after it was moved to include/asm-arm/arch-omap/ (commit d23b6a447c9cd1d7376c5ec109b4be015a121eec), and then to arch/arm/plat-omap/include/map/. Can I do anything to get omap_dsp_init() back into the omap tree? Could I just start with readding that old dsp_common.c, including any necessary header files, back to arch/arm/plat-omap/dsp? Or what other way should I take to restore omap1510 mcbsp1/3 support back? Thanks, Janusz -- 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
musb otg changes break booting on omaps
Hi Dave Felipe, Looks like commit 84e250ffa76dddc1bad84e04248a27f442c25986 musb: proper hookup to transceiver drivers breaks booting on omaps if no transceiver is configured. Got any patches for that? Regards, Tony 6musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0 4Platform driver 'musb_hdrc' needs updating - please use dev_pm_ops 3HS USB OTG: no transceiver configured 3musb_hdrc musb_hdrc: musb_init_controller failed with status -19 1Unable to handle kernel NULL pointer dereference at virtual address 0028 1pgd = c0004000 1[0028] *pgd= Internal error: Oops: 5 [#1] dModules linked in: CPU: 0Not tainted (2.6.30-08336-ge9ef5af #417) PC is at musb_platform_suspend+0x40/0x88 LR is at musb_platform_suspend+0x3c/0x88 pc : [c027905c]lr : [c0279058]psr: a013 sp : cf823de8 ip : fp : c050b1a0 r10: r9 : r8 : c052e5b0 r7 : c0534bdc r6 : cf8190e8 r5 : cf8190e8 r4 : cf8190e8 r3 : c0505ce0 r2 : cf822000 r1 : d80ab404 r0 : Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 80004019 DAC: 0017 Process swapper (pid: 1, stack limit = 0xcf8222f0) Stack: (0xcf823de8 to 0xcf824000) 3de0: cf8190e8 c02790b0 c0277aec ffed 3e00: cf8190e8 c001d8b8 0001 cf804184 0001 cf804180 c050b198 3e20: 005c d80ab000 c050b17c c01ca068 cf823e84 c03acff4 3e40: cf8741e0 cf823ea8 cf8537e0 cf823ea8 c0106be8 0001 3e60: cf874180 cf823ea8 cf8741e0 c01067b8 cf874180 cf8741e0 cf823ea8 c0106890 3e80: cf823ea8 cf8741e0 cf874180 cf8741e0 cf8741e0 cf823ea8 cf8537e0 3ea0: 0001 c0107834 cf8537e0 c050b1a0 c050b1d4 c0534bdc 3ec0: c0534bdc c052e5b0 c0200e28 c050b1a0 c024 3ee0: c050b1a0 c050b1d4 c0534bdc c0534bdc c052e5b0 c0200110 cf823f08 3f00: c02000b0 c01ff3ec cf802d08 cf852f40 c0534bdc c04fe0c4 c0534bdc cf91f9c0 3f20: 0060 c01ffa1c c03d0200 c03d0200 cf824000 c0026034 c0534bdc c05445c0 3f40: c001cd44 c02003e0 c0026034 c0534bc0 c05445c0 3f60: c001cd44 c020120c c0026034 c05445c0 c002b290 3f80: c01007d4 cf823fb4 c0468f1c 8100 024e c0519018 cf84ed80 3fa0: c0519018 015f c055bec8 c0100928 c0468f1c cf84ed00 cf823fc6 c0083690 3fc0: 35334d80 0031 c0026034 3fe0: c0008860 c002cd84 [c027905c] (musb_platform_suspend+0x40/0x88) from [c02790b0] (musb_platform) [c02790b0] (musb_platform_exit+0xc/0x20) from [c0277aec] (musb_free+0x74/0x) [c0277aec] (musb_free+0x74/0xb8) from [c001d8b8] (musb_probe+0x9d4/0xbac) [c001d8b8] (musb_probe+0x9d4/0xbac) from [c0200e28] (platform_drv_probe+0x1) [c0200e28] (platform_drv_probe+0x18/0x1c) from [c024] (driver_probe_dev) [c024] (driver_probe_device+0xa0/0x14c) from [c0200110] (__driver_attac) [c0200110] (__driver_attach+0x60/0x84) from [c01ff3ec] (bus_for_each_dev+0x) [c01ff3ec] (bus_for_each_dev+0x44/0x78) from [c01ffa1c] (bus_add_driver+0xf) [c01ffa1c] (bus_add_driver+0xf0/0x274) from [c02003e0] (driver_register+0xa) [c02003e0] (driver_register+0xa8/0x130) from [c020120c] (platform_driver_pr) [c020120c] (platform_driver_probe+0x10/0x88) from [c002b290] (do_one_initca) [c002b290] (do_one_initcall+0x50/0x17c) from [c0008860] (kernel_init+0x8c/0) [c0008860] (kernel_init+0x8c/0x104) from [c002cd84] (kernel_thread_exit+0x0) Code: e59f104c e384 ebf712f8 e594009c (e5903028) 4---[ end trace 1b75b31a2719ed1c ]--- 0Kernel panic - not syncing: Attempted to kill init! -- 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] OMAP2/3: mmc-twl4030: Free up MMC regulators while cleaning up
twl_mmc_cleanup() must free up the regulators that were
allocated by twl_mmc_late_init().
This eliminates the below error when 'omap_hsmmc' module is
repeatedly loaded and unloaded.
sysfs: cannot create duplicate filename '/devices/platform
/mmci-omap-hs.0/microamps_requested_vmmc'
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
---
arch/arm/mach-omap2/mmc-twl4030.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 06b252f..0007115 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -119,6 +119,7 @@ static int twl_mmc_late_init(struct device *dev)
if (i != 0)
break;
ret = PTR_ERR(reg);
+ hsmmc[i].vcc = NULL;
goto err;
}
hsmmc[i].vcc = reg;
@@ -165,8 +166,13 @@ done:
static void twl_mmc_cleanup(struct device *dev)
{
struct omap_mmc_platform_data *mmc = dev-platform_data;
+ int i;
gpio_free(mmc-slots[0].switch_pin);
+ for(i = 0; i ARRAY_SIZE(hsmmc); i++) {
+ regulator_put(hsmmc[i].vcc);
+ regulator_put(hsmmc[i].vcc_aux);
+ }
}
#ifdef CONFIG_PM
--
1.6.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 1/1] i2c:OMAP3:Errata workaround for spurious RDR event
-Original Message- From: Menon, Nishanth Sent: Monday, June 22, 2009 11:21 PM To: Hald, Ulrik Bech; linux-omap@vger.kernel.org Cc: Hald, Ulrik Bech Subject: RE: [PATCH 1/1] i2c:OMAP3:Errata workaround for spurious RDR event -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Ulrik Bech Hald Sent: Monday, June 22, 2009 11:25 PM To: linux-omap@vger.kernel.org Cc: Hald, Ulrik Bech Subject: [PATCH 1/1] i2c:OMAP3:Errata workaround for spurious RDR event Under certain rare conditions, I2C_STAT[13].RDR bit may be set, and the corresponding interrupt fire, even when there is no data in the receive FIFO, or the I2C data transfer is still ongoing. These spurious RDR events must be ignored by the software. Is this workaround valid for omap2430 also? Yes, this workaround should also be valid for OMAP2430 errata 1.67 (equivalent errata). Regards, Nishanth Menon BR Ulrik -- 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: OMAP34XXCAM: Micron mt9d111 sensor support?
-Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Monday, June 22, 2009 1:06 PM To: Aguirre Rodriguez, Sergio Alberto Cc: Zach LeRoy; linux-omap; linux-me...@vger.kernel.org; Sakari Ailus Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support? Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy Sent: Wednesday, June 17, 2009 5:06 PM To: linux-omap; linux-me...@vger.kernel.org Subject: OMAP34XXCAM: Micron mt9d111 sensor support? I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video in) Sadly, the tree above (omap3-linux-camera-driver) won't build for the Zoom/LDP: CC arch/arm/mach-omap2/board-ldp-camera.o /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: implicit declaration of function 'PAGE_ALIGN' /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: initializer element is not constant /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: (near initialization for 'ov3640_hwc.capture_mem') /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c: In function 'ov3640_sensor_set_prv_data': /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: 'hwc' undeclared (first use in this function) /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: (Each undeclared identifier is reported only once /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: for each function it appears in.) Looking at the code, it seems that some pieces are missing - merge problem maybe? Hi Gary, I'm currently on the process to rebase and verify all this code on 3430SDP, Zoom1 and soon Zoom2. Here you can find my progress: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Check devel branch, which contains all latest Sakari's tree patches (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM tree, plus the patches, which are still in works, to make the above mentioned platforms to work. I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right now... My gitorious tree will eventually disappear, as I can work better with this new one. I'll consolidate some patches when this sensor code is ready, and will CC you if interested. Regards, Sergio -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP34XXCAM: Micron mt9d111 sensor support?
Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Monday, June 22, 2009 1:06 PM To: Aguirre Rodriguez, Sergio Alberto Cc: Zach LeRoy; linux-omap; linux-me...@vger.kernel.org; Sakari Ailus Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support? Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy Sent: Wednesday, June 17, 2009 5:06 PM To: linux-omap; linux-me...@vger.kernel.org Subject: OMAP34XXCAM: Micron mt9d111 sensor support? I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video in) Sadly, the tree above (omap3-linux-camera-driver) won't build for the Zoom/LDP: CC arch/arm/mach-omap2/board-ldp-camera.o /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: implicit declaration of function 'PAGE_ALIGN' /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: initializer element is not constant /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: (near initialization for 'ov3640_hwc.capture_mem') /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c: In function 'ov3640_sensor_set_prv_data': /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: 'hwc' undeclared (first use in this function) /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: (Each undeclared identifier is reported only once /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: for each function it appears in.) Looking at the code, it seems that some pieces are missing - merge problem maybe? Hi Gary, I'm currently on the process to rebase and verify all this code on 3430SDP, Zoom1 and soon Zoom2. Here you can find my progress: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Check devel branch, which contains all latest Sakari's tree patches (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM tree, plus the patches, which are still in works, to make the above mentioned platforms to work. I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right now... My gitorious tree will eventually disappear, as I can work better with this new one. I'll consolidate some patches when this sensor code is ready, and will CC you if interested. Thanks. I've already checked out this tree and at least it builds for the Zoom (I have one here). Is this in a state where I can test it for you? What do you use to capture video from the sensor? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP34XXCAM: Micron mt9d111 sensor support?
Aguirre Rodriguez, Sergio Alberto wrote: From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto From: Gary Thomas [mailto:g...@mlbassoc.com] Aguirre Rodriguez, Sergio Alberto wrote: From: Gary Thomas [mailto:g...@mlbassoc.com] Aguirre Rodriguez, Sergio Alberto wrote: From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) I'd like to move forward using this on OMAP/3530 with TVP5150 (S- video in) Sadly, the tree above (omap3-linux-camera-driver) won't build for the Zoom/LDP: CC arch/arm/mach-omap2/board-ldp-camera.o /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: implicit declaration of function 'PAGE_ALIGN' /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: initializer element is not constant /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: (near initialization for 'ov3640_hwc.capture_mem') /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c: In function 'ov3640_sensor_set_prv_data': /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: 'hwc' undeclared (first use in this function) /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: (Each undeclared identifier is reported only once /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: for each function it appears in.) Looking at the code, it seems that some pieces are missing - merge problem maybe? Hi Gary, I'm currently on the process to rebase and verify all this code on 3430SDP, Zoom1 and soon Zoom2. Here you can find my progress: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Check devel branch, which contains all latest Sakari's tree patches (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM tree, plus the patches, which are still in works, to make the above mentioned platforms to work. I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right now... My gitorious tree will eventually disappear, as I can work better with this new one. I'll consolidate some patches when this sensor code is ready, and will CC you if interested. Thanks. I've already checked out this tree and at least it builds for the Zoom (I have one here). Is this in a state where I can test it for you? What do you use to capture video from the sensor? I normally use a small test binary I wrote which saves the captured frames to memory, so later I can see them with either IrfanView (when capturing RAW images) or PYUV for seeing the YUV422 images. You should be able to use any standard V4l2 capturing application anyways. Btw, any contribution would be completely welcome. Either on Testing or on development. :) Thanks for your interest in helping. I've built for the Zoom, now I just need to figure out how to capture the data. I'll let you know if I have any questions or problems. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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][OMAP3:I2C]Workaround for OMAP3430 I2C silicon errata 1.153
Hello,
Menon, Nishanth wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sonasath, Moiz
Sent: Monday, June 22, 2009 7:50 PM
To: linux-omap@vger.kernel.org
Cc: Pandita, Vikram
Subject: [PATCH] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon
errata 1.153
This patch includes the workarround for I2C Errata 1.153: When an XRDY/XDR
is hit, wait for XUDF before writing data to DATA_REG
Is this workaround valid for omap2430 also?
Some kind of such workaround needs to be applied and for OMAP1 ISR too.
I had
the same problem on our OMAP5910 based custom made board. While writing
a large contiguous amount of data constantly occurs a situation when
dev-buf_len = 0, but I2C_CNT register != 0, and, as result, I2C
controller doesn't generate ARDY IRQ, no complete_cmd occurs in ISR, and
we get controller timed out issues then...
So, here is a part of modified OMAP1 ISR. It works for me at least.
/*
* Is there a bug in the OMAP5910 I2C controller? It
* generates a bunch of fake XRDY interrupts under high load.
* As result, there is a very high chance to have a situation
* when dev-buf_len = 0 already, but I2C_CNT != 0. So, there
* is no ARDY irq then, no complete_cmd, controller timed out
* issues...
*
* Workaround:
*
* When we get XRDY interrupt without transmit underflow flag
* (XUDF bit in the I2C_STAT register), delay for 100 microsecs
* and ignore it.
*
* We write data into I2C_DATA register in case of transmit
* underflow condition ONLY.
*/
if (stat OMAP_I2C_STAT_XRDY) {
if (!(stat OMAP_I2C_STAT_XUDF)) {
udelay(100);
continue;
} else {
w = 0;
if (dev-buf_len) {
w = *dev-buf++;
dev-buf_len--;
if (dev-buf_len) {
w |= *dev-buf++ 8;
dev-buf_len--;
}
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
} else {
dev_err(dev-dev, XRDY IRQ while no
data to send\n);
break;
}
continue;
}
}
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
Can a phone hook switch follow alsa jack model?
Hi, I am wondering if it is a good idea to create support for a phone hook switch, or a handset pick up switch, like that found on Amstrad E3 (Delta) videophone, using alsa jack framework. After my initial attempt to add support for the switch using gpio-keys driver, I am no longer sure if it is a good idea to follow the keyboard model, that the driver has been designed after, for driving a switch that has nothing to do with keyboards and may required a different approach. OTOH, the switch is closely related to a handset, and handsets can be seen as sound devices, can't they? So maybe alsa jack would fit better than keyboard? However, I am not sure if the switch in question matches the alsa jack model closely enough. I see the switch usage not as simple as turning handset microphone/speaker on or off. It can be used for other purposes as well, like accepting a phone call or actually dialing a number that has been just typed in. Furthermore, it can be used to turn off a speakerphone function, while, in turn, the related handset microphone/speaker pair can be turned off not only with this switch, but with a handsfree button as well, for example. All that extra functionality looks like belonging to userspace rather then kernel, not like other alsa jack implementations that seem to do all the job of switching media paths inside the kernel. That is why I am not sure if the jack model is suitable for the purpose. Thanks, Janusz -- 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: OMAP34XXCAM: Micron mt9d111 sensor support?
-Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Tuesday, June 23, 2009 8:23 AM To: Aguirre Rodriguez, Sergio Alberto Cc: Zach LeRoy; linux-omap; linux-me...@vger.kernel.org; Sakari Ailus Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support? Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Monday, June 22, 2009 1:06 PM To: Aguirre Rodriguez, Sergio Alberto Cc: Zach LeRoy; linux-omap; linux-me...@vger.kernel.org; Sakari Ailus Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support? Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy Sent: Wednesday, June 17, 2009 5:06 PM To: linux-omap; linux-me...@vger.kernel.org Subject: OMAP34XXCAM: Micron mt9d111 sensor support? I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video in) Sadly, the tree above (omap3-linux-camera-driver) won't build for the Zoom/LDP: CC arch/arm/mach-omap2/board-ldp-camera.o /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: implicit declaration of function 'PAGE_ALIGN' /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: initializer element is not constant /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: (near initialization for 'ov3640_hwc.capture_mem') /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c: In function 'ov3640_sensor_set_prv_data': /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: 'hwc' undeclared (first use in this function) /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: (Each undeclared identifier is reported only once /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: for each function it appears in.) Looking at the code, it seems that some pieces are missing - merge problem maybe? Hi Gary, I'm currently on the process to rebase and verify all this code on 3430SDP, Zoom1 and soon Zoom2. Here you can find my progress: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Check devel branch, which contains all latest Sakari's tree patches (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM tree, plus the patches, which are still in works, to make the above mentioned platforms to work. I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right now... My gitorious tree will eventually disappear, as I can work better with this new one. I'll consolidate some patches when this sensor code is ready, and will CC you if interested. Thanks. I've already checked out this tree and at least it builds for the Zoom (I have one here). Is this in a state where I can test it for you? What do you use to capture video from the sensor? I normally use a small test binary I wrote which saves the captured frames to memory, so later I can see them with either IrfanView (when capturing RAW images) or PYUV for seeing the YUV422 images. You should be able to use any standard V4l2 capturing application anyways. Regards, Sergio -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to
RE: OMAP34XXCAM: Micron mt9d111 sensor support?
From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto From: Gary Thomas [mailto:g...@mlbassoc.com] Aguirre Rodriguez, Sergio Alberto wrote: From: Gary Thomas [mailto:g...@mlbassoc.com] Aguirre Rodriguez, Sergio Alberto wrote: From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) I'd like to move forward using this on OMAP/3530 with TVP5150 (S- video in) Sadly, the tree above (omap3-linux-camera-driver) won't build for the Zoom/LDP: CC arch/arm/mach-omap2/board-ldp-camera.o /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: implicit declaration of function 'PAGE_ALIGN' /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: initializer element is not constant /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: (near initialization for 'ov3640_hwc.capture_mem') /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c: In function 'ov3640_sensor_set_prv_data': /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: 'hwc' undeclared (first use in this function) /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: (Each undeclared identifier is reported only once /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: for each function it appears in.) Looking at the code, it seems that some pieces are missing - merge problem maybe? Hi Gary, I'm currently on the process to rebase and verify all this code on 3430SDP, Zoom1 and soon Zoom2. Here you can find my progress: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Check devel branch, which contains all latest Sakari's tree patches (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM tree, plus the patches, which are still in works, to make the above mentioned platforms to work. I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right now... My gitorious tree will eventually disappear, as I can work better with this new one. I'll consolidate some patches when this sensor code is ready, and will CC you if interested. Thanks. I've already checked out this tree and at least it builds for the Zoom (I have one here). Is this in a state where I can test it for you? What do you use to capture video from the sensor? I normally use a small test binary I wrote which saves the captured frames to memory, so later I can see them with either IrfanView (when capturing RAW images) or PYUV for seeing the YUV422 images. You should be able to use any standard V4l2 capturing application anyways. Btw, any contribution would be completely welcome. Either on Testing or on development. :) Thanks for your interest in helping. Regards, Sergio -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media 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
[RESEND][PATCH 2/2] McSPI Slave and DMA,FIFO support
This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput.
This has a dependency on patch
[RESEND][PATCH 1/2] McSPI Slave and DMA,FIFO support
Signed-off-by: Hemanth V heman...@ti.com
drivers/spi/omap2_mcspi.c | 353 --
1 files changed, 314 insertions(+), 39 deletions(-)
Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
===
--- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c 2009-06-23
16:46:19.0
+0530
+++ linux-omap-2.6/drivers/spi/omap2_mcspi.c2009-06-23 18:38:40.0
+0530
@@ -37,9 +37,11 @@
#include mach/dma.h
#include mach/clock.h
+#include mach/mcspi.h
#define OMAP2_MCSPI_MAX_FREQ 4800
+#define OMAP2_MCSPI_MAX_FIFODEPTH 64
#define OMAP2_MCSPI_REVISION 0x00
#define OMAP2_MCSPI_SYSCONFIG 0x10
@@ -49,6 +51,7 @@
#define OMAP2_MCSPI_WAKEUPENABLE 0x20
#define OMAP2_MCSPI_SYST 0x24
#define OMAP2_MCSPI_MODULCTRL 0x28
+#define OMAP2_MCSPI_XFERLEVEL 0x7c
/* per-channel banks, 0x14 bytes each, first is: */
#define OMAP2_MCSPI_CHCONF00x2c
@@ -83,10 +86,13 @@
#define OMAP2_MCSPI_CHCONF_IS (1 18)
#define OMAP2_MCSPI_CHCONF_TURBO (1 19)
#define OMAP2_MCSPI_CHCONF_FORCE (1 20)
+#define OMAP2_MCSPI_CHCONF_FFET(1 27)
+#define OMAP2_MCSPI_CHCONF_FFER(1 28)
#define OMAP2_MCSPI_CHSTAT_RXS (1 0)
#define OMAP2_MCSPI_CHSTAT_TXS (1 1)
#define OMAP2_MCSPI_CHSTAT_EOT (1 2)
+#define OMAP2_MCSPI_IRQ_EOW(1 17)
#define OMAP2_MCSPI_CHCTRL_EN (1 0)
@@ -122,6 +128,10 @@
unsigned long phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma *dma_channels;
+ unsigned short mcspi_mode;
+ unsigned short dma_mode;
+ unsigned short force_cs_mode;
+ unsigned short fifo_depth;
};
struct omap2_mcspi_cs {
@@ -130,6 +140,37 @@
int word_len;
};
+#ifdef CONFIG_SPI_DEBUG
+struct reg_type {
+ char name[40];
+ int offset;
+};
+
+static struct reg_type reg_map[] = {
+ {MCSPI_REV, 0x0},
+ {MCSPI_SYSCONFIG, 0x10},
+ {MCSPI_SYSSTATUS, 0x14},
+ {MCSPI_IRQSTATUS, 0x18},
+ {MCSPI_IRQENABLE, 0x1C},
+ {MCSPI_WAKEUPENABLE, 0x20},
+ {MCSPI_SYST, 0x24},
+ {MCSPI_MODULCTRL, 0x28},
+ {MCSPI_XFERLEVEL, 0x7c},
+ {CH0, 0x2C},
+ {CH1, 0x40},
+ {CH2, 0x54},
+ {CH3, 0x68}
+};
+
+static struct reg_type ch_reg_type[] = {
+ {CONF, 0x00},
+ {STAT, 0x04},
+ {CTRL, 0x08},
+ {TX, 0x0C},
+ {RX, 0x10},
+};
+#endif
+
static struct workqueue_struct *omap2_mcspi_wq;
#define MOD_REG_BIT(val, mask, set) do { \
@@ -185,6 +226,39 @@
mcspi_write_cs_reg(spi, OMAP2_MCSPI_CHCONF0, l);
}
+#ifdef CONFIG_SPI_DEBUG
+static int
+omap2_mcspi_dump_regs(struct spi_master *master)
+{
+ u32 spi_base;
+ u32 reg;
+ u32 channel;
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+
+ spi_base = (u32)mcspi-base;
+
+ for (reg = 0; (reg ARRAY_SIZE(reg_map)); reg++) {
+ struct reg_type *reg_d = reg_map[reg];
+ u32 base1 = spi_base + reg_d-offset;
+ if (reg_d-name[0] == 'C') {
+ for (channel = 0; (channel (ARRAY_SIZE(ch_reg_type)));
+ channel++) {
+ struct reg_type *reg_c = ch_reg_type[channel];
+ u32 base2 = base1 + reg_c-offset;
+ pr_debug(MCSPI_%s%s [0x%08X] = 0x%08X\n,
+ reg_d-name, reg_c-name, base2,
+ __raw_readl(base2));
+ }
+ } else {
+ pr_debug(%s : [0x%08X] = 0x%08X\n,
+ reg_d-name, base1, __raw_readl(base1));
+ }
+
+ }
+ return 0;
+}
+#endif
+
static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
{
u32 l;
@@ -202,34 +276,160 @@
mcspi_write_cs_reg(spi, OMAP2_MCSPI_CHCONF0, l);
}
+static int omap2_mcspi_set_txfifo(const struct spi_device *spi, int buf_size,
+ int enable)
+{
+ u32 l, rw, s;
+ unsigned short revert = 0;
+ struct spi_master *master = spi-master;
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+
+ l = mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHCONF0);
+ s = mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHCTRL0);
+
+ if (enable == 1) {
+
+ /* FIFO cannot be enabled for both TX and RX
+* simultaneously
+*/
+ if (l OMAP2_MCSPI_CHCONF_FFER)
+
[PATCH 13/12] OMAP: Fix IOMEM macro for assembly
Here's one more fix. Tony From 503dcbeba50fd3545283594bc391b4a400fa6c48 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Tue, 23 Jun 2009 16:55:30 +0300 Subject: [PATCH] OMAP: Fix IOMEM macro for assembly Otherwise IOMEM calculations can fail. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/plat-omap/include/mach/io.h b/arch/arm/plat-omap/include/mach/io.h index 3b28147..73f483d 100644 --- a/arch/arm/plat-omap/include/mach/io.h +++ b/arch/arm/plat-omap/include/mach/io.h @@ -201,7 +201,7 @@ #define OMAP2_IO_ADDRESS(pa) IOMEM(__OMAP2_IO_ADDRESS(pa)) #ifdef __ASSEMBLER__ -#define IOMEM(x) x +#define IOMEM(x) (x) #else #define IOMEM(x) ((void __force __iomem *)(x))
[RESEND][PATCH 1/2] McSPI Slave and DMA,FIFO support
This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput. Platform config
parameters have been added to enable these features on any particular
McSPI controller.
FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs
to be a multiple of buffer size that is used for read/write.
These features are useful when you have high throughput devices
like WLAN or Modem connected over SPI.
Signed-off-by: Hemanth V heman...@ti.com
arch/arm/mach-omap2/devices.c |5 +
arch/arm/plat-omap/include/mach/mcspi.h | 16
2 files changed, 21 insertions(+)
---
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2009-06-18
15:22:39.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c2009-06-23
16:45:51.0
+0530
@@ -259,6 +259,7 @@
static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
+ .force_cs_mode = 1,
};
static struct resource omap2_mcspi1_resources[] = {
@@ -281,6 +282,10 @@
static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
.num_cs = 2,
+ .mode = OMAP2_MCSPI_MASTER,
+ .dma_mode = 1,
+ .force_cs_mode = 0,
+ .fifo_depth = 0,
};
static struct resource omap2_mcspi2_resources[] = {
Index: linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/include/mach/mcspi.h 2009-06-18
15:22:39.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h 2009-06-23
16:45:51.0 +0530
@@ -1,8 +1,24 @@
#ifndef _OMAP2_MCSPI_H
#define _OMAP2_MCSPI_H
+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE 1
+
struct omap2_mcspi_platform_config {
unsigned short num_cs;
+
+ /* SPI is master or slave */
+ unsigned short mode;
+
+ /* Use only DMA for data transfers */
+ unsigned short dma_mode;
+
+ /* Force chip select mode */
+ unsigned short force_cs_mode;
+
+ /* FIFO depth in bytes, max value 64 */
+ unsigned short fifo_depth;
+
};
struct omap2_mcspi_device_config {
--
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] OMAP: Remove OMAP_IO_ADDRESS, use OMAP1_IO_ADDRESS and OMAP2_IO_ADDRESS instead
Search and replace OMAP_IO_ADDRESS with OMAP1_IO_ADDRESS and OMAP2_IO_ADDRESS,
and convert omap_read/write into a functions instead of a macros.
Also rename OMAP_MPUIO_VBASE to OMAP1_MPUIO_VBASE.
In the long run, most code should use ioremap + __raw_read/write instead.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/devices.c |2 -
arch/arm/mach-omap1/pm.h |4 +
arch/arm/mach-omap1/serial.c |6 +-
arch/arm/mach-omap1/sram.S| 12 ++-
arch/arm/mach-omap1/time.c|4 +
arch/arm/mach-omap2/board-4430sdp.c |4 +
arch/arm/mach-omap2/cm.h |6 +-
arch/arm/mach-omap2/omap-smp.c|2 -
arch/arm/mach-omap2/pm-debug.c|2 -
arch/arm/mach-omap2/prm.h |6 +-
arch/arm/mach-omap2/sdrc.h|6 +-
arch/arm/mach-omap2/serial.c |6 +-
arch/arm/mach-omap2/sram242x.S|4 +
arch/arm/mach-omap2/sram243x.S|4 +
arch/arm/mach-omap2/timer-gp.c|2 -
arch/arm/plat-omap/dma.c |8 +-
arch/arm/plat-omap/dmtimer.c |5 +
arch/arm/plat-omap/gpio.c | 86 +
arch/arm/plat-omap/include/mach/control.h | 12 ++-
arch/arm/plat-omap/include/mach/entry-macro.S |8 +-
arch/arm/plat-omap/include/mach/io.h | 64 ++-
arch/arm/plat-omap/include/mach/mtd-xip.h |2 -
arch/arm/plat-omap/include/mach/omap44xx.h|8 +-
arch/arm/plat-omap/include/mach/sdrc.h|6 +-
arch/arm/plat-omap/io.c | 58 +
arch/arm/plat-omap/sram.c | 20 +++---
drivers/video/omap/dispc.c|6 +-
27 files changed, 196 insertions(+), 157 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index bbbaeb0..0680843 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -71,7 +71,7 @@ static inline void omap_init_rtc(void) {}
# define INT_DSP_MAILBOX1 INT_1610_DSP_MAILBOX1
#endif
-#define OMAP1_MBOX_BASEIO_ADDRESS(OMAP16XX_MAILBOX_BASE)
+#define OMAP1_MBOX_BASEOMAP1_IO_ADDRESS(OMAP16XX_MAILBOX_BASE)
static struct resource mbox_resources[] = {
{
diff --git a/arch/arm/mach-omap1/pm.h b/arch/arm/mach-omap1/pm.h
index 9ed5e2c..c4f05bd 100644
--- a/arch/arm/mach-omap1/pm.h
+++ b/arch/arm/mach-omap1/pm.h
@@ -39,11 +39,11 @@
* Register and offset definitions to be used in PM assembler code
*
*/
-#define CLKGEN_REG_ASM_BASEIO_ADDRESS(0xfffece00)
+#define CLKGEN_REG_ASM_BASEOMAP1_IO_ADDRESS(0xfffece00)
#define ARM_IDLECT1_ASM_OFFSET 0x04
#define ARM_IDLECT2_ASM_OFFSET 0x08
-#define TCMIF_ASM_BASE IO_ADDRESS(0xfffecc00)
+#define TCMIF_ASM_BASE OMAP1_IO_ADDRESS(0xfffecc00)
#define EMIFS_CONFIG_ASM_OFFSET0x0c
#define EMIFF_SDRAM_CONFIG_ASM_OFFSET 0x20
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index f754cee..6f54b2c 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -64,7 +64,7 @@ static void __init omap_serial_reset(struct
plat_serial8250_port *p)
static struct plat_serial8250_port serial_platform_data[] = {
{
- .membase= IO_ADDRESS(OMAP_UART1_BASE),
+ .membase= OMAP1_IO_ADDRESS(OMAP_UART1_BASE),
.mapbase= OMAP_UART1_BASE,
.irq= INT_UART1,
.flags = UPF_BOOT_AUTOCONF,
@@ -73,7 +73,7 @@ static struct plat_serial8250_port serial_platform_data[] = {
.uartclk= OMAP16XX_BASE_BAUD * 16,
},
{
- .membase= IO_ADDRESS(OMAP_UART2_BASE),
+ .membase= OMAP1_IO_ADDRESS(OMAP_UART2_BASE),
.mapbase= OMAP_UART2_BASE,
.irq= INT_UART2,
.flags = UPF_BOOT_AUTOCONF,
@@ -82,7 +82,7 @@ static struct plat_serial8250_port serial_platform_data[] = {
.uartclk= OMAP16XX_BASE_BAUD * 16,
},
{
- .membase= IO_ADDRESS(OMAP_UART3_BASE),
+ .membase= OMAP1_IO_ADDRESS(OMAP_UART3_BASE),
.mapbase= OMAP_UART3_BASE,
.irq= INT_UART3,
.flags = UPF_BOOT_AUTOCONF,
diff --git a/arch/arm/mach-omap1/sram.S b/arch/arm/mach-omap1/sram.S
index 261cdc4..7724e52 100644
--- a/arch/arm/mach-omap1/sram.S
+++ b/arch/arm/mach-omap1/sram.S
@@ -21,13 +21,13 @@
ENTRY(omap1_sram_reprogram_clock)
[PATCH 2/3] OMAP: Rename OMAP_MPUIO_BASE to OMAP1_MPUIO_BASE
Rename OMAP_MPUIO_BASE to OMAP1_MPUIO_BASE
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/gpio.c |4 ++--
arch/arm/plat-omap/include/mach/gpio.h |2 +-
drivers/input/keyboard/omap-keypad.c | 22 +++---
drivers/mtd/nand/ams-delta.c |8
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 978b30e..555bab0 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -99,7 +99,7 @@
#define OMAP850_GPIO_INT_MASK 0x10
#define OMAP850_GPIO_INT_STATUS0x14
-#define OMAP1_MPUIO_VBASE OMAP1_IO_ADDRESS(OMAP_MPUIO_BASE)
+#define OMAP1_MPUIO_VBASE OMAP1_IO_ADDRESS(OMAP1_MPUIO_BASE)
/*
* omap24xx specific GPIO registers
@@ -224,7 +224,7 @@ static struct gpio_bank gpio_bank_730[7] = {
#ifdef CONFIG_ARCH_OMAP850
static struct gpio_bank gpio_bank_850[7] = {
- { OMAP_MPUIO_BASE, INT_850_MPUIO, IH_MPUIO_BASE,
METHOD_MPUIO },
+ { OMAP1_MPUIO_BASE, INT_850_MPUIO, IH_MPUIO_BASE,
METHOD_MPUIO },
{ OMAP850_GPIO1_BASE, INT_850_GPIO_BANK1, IH_GPIO_BASE,
METHOD_GPIO_850 },
{ OMAP850_GPIO2_BASE, INT_850_GPIO_BANK2, IH_GPIO_BASE + 32,
METHOD_GPIO_850 },
{ OMAP850_GPIO3_BASE, INT_850_GPIO_BANK3, IH_GPIO_BASE + 64,
METHOD_GPIO_850 },
diff --git a/arch/arm/plat-omap/include/mach/gpio.h
b/arch/arm/plat-omap/include/mach/gpio.h
index 2b22a87..633ff68 100644
--- a/arch/arm/plat-omap/include/mach/gpio.h
+++ b/arch/arm/plat-omap/include/mach/gpio.h
@@ -29,7 +29,7 @@
#include linux/io.h
#include mach/irqs.h
-#define OMAP_MPUIO_BASE0xfffb5000
+#define OMAP1_MPUIO_BASE 0xfffb5000
#if (defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850))
diff --git a/drivers/input/keyboard/omap-keypad.c
b/drivers/input/keyboard/omap-keypad.c
index 87ec7b1..bba85ad 100644
--- a/drivers/input/keyboard/omap-keypad.c
+++ b/drivers/input/keyboard/omap-keypad.c
@@ -116,7 +116,7 @@ static irqreturn_t omap_kp_interrupt(int irq, void *dev_id)
}
} else
/* disable keyboard interrupt and schedule for handling */
- omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
+ omap_writew(1, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
tasklet_schedule(kp_tasklet);
@@ -143,20 +143,20 @@ static void omap_kp_scan_keypad(struct omap_kp *omap_kp,
unsigned char *state)
} else {
/* disable keyboard interrupt and schedule for handling */
- omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
+ omap_writew(1, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
/* read the keypad status */
- omap_writew(0xff, OMAP_MPUIO_BASE + OMAP_MPUIO_KBC);
+ omap_writew(0xff, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBC);
for (col = 0; col omap_kp-cols; col++) {
omap_writew(~(1 col) 0xff,
- OMAP_MPUIO_BASE + OMAP_MPUIO_KBC);
+ OMAP1_MPUIO_BASE + OMAP_MPUIO_KBC);
udelay(omap_kp-delay);
- state[col] = ~omap_readw(OMAP_MPUIO_BASE +
+ state[col] = ~omap_readw(OMAP1_MPUIO_BASE +
OMAP_MPUIO_KBR_LATCH) 0xff;
}
- omap_writew(0x00, OMAP_MPUIO_BASE + OMAP_MPUIO_KBC);
+ omap_writew(0x00, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBC);
udelay(2);
}
}
@@ -234,7 +234,7 @@ static void omap_kp_tasklet(unsigned long data)
for (i = 0; i omap_kp_data-rows; i++)
enable_irq(gpio_to_irq(row_gpios[i]));
} else {
- omap_writew(0, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
+ omap_writew(0, OMAP1_MPUIO_BASE +
OMAP_MPUIO_KBD_MASKIT);
kp_cur_group = -1;
}
}
@@ -317,7 +317,7 @@ static int __devinit omap_kp_probe(struct platform_device
*pdev)
/* Disable the interrupt for the MPUIO keyboard */
if (!cpu_is_omap24xx())
- omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
+ omap_writew(1, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
keymap = pdata-keymap;
@@ -391,7 +391,7 @@ static int __devinit omap_kp_probe(struct platform_device
*pdev)
}
if (pdata-dbounce)
- omap_writew(0xff, OMAP_MPUIO_BASE + OMAP_MPUIO_GPIO_DEBOUNCING);
+ omap_writew(0xff, OMAP1_MPUIO_BASE +
OMAP_MPUIO_GPIO_DEBOUNCING);
/* scan current status and enable interrupt */
omap_kp_scan_keypad(omap_kp, keypad_state);
@@ -402,7 +402,7 @@ static int __devinit
[PATCH 3/3] OMAP: Remove ifdefs for io.h
Remove ifdefs for io.h
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/io.c |6 +++---
arch/arm/plat-omap/include/mach/io.h | 37 +++---
arch/arm/plat-omap/io.c |4 ++--
3 files changed, 34 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index 3afe540..7030f92 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -29,9 +29,9 @@ extern void omapfb_reserve_sdram(void);
*/
static struct map_desc omap_io_desc[] __initdata = {
{
- .virtual= IO_VIRT,
- .pfn= __phys_to_pfn(IO_PHYS),
- .length = IO_SIZE,
+ .virtual= OMAP1_IO_VIRT,
+ .pfn= __phys_to_pfn(OMAP1_IO_PHYS),
+ .length = OMAP1_IO_SIZE,
.type = MT_DEVICE
}
};
diff --git a/arch/arm/plat-omap/include/mach/io.h
b/arch/arm/plat-omap/include/mach/io.h
index 8541388..c4886f9 100644
--- a/arch/arm/plat-omap/include/mach/io.h
+++ b/arch/arm/plat-omap/include/mach/io.h
@@ -66,13 +66,21 @@
#define OMAP2_IO_OFFSET0x9000
#define OMAP2_IO_ADDRESS(pa) IOMEM((pa) + OMAP2_IO_OFFSET) /* L3 and L4 */
-#if defined(CONFIG_ARCH_OMAP1)
+/*
+ *
+ * Omap1 specific IO mapping
+ *
+ */
-#define IO_PHYS0xFFFB
-#define IO_SIZE0x4
-#define IO_VIRT(IO_PHYS - OMAP1_IO_OFFSET)
+#define OMAP1_IO_PHYS 0xFFFB
+#define OMAP1_IO_SIZE 0x4
+#define OMAP1_IO_VIRT (OMAP1_IO_PHYS - OMAP1_IO_OFFSET)
-#elif defined(CONFIG_ARCH_OMAP2)
+/*
+ *
+ * Omap2 specific IO mapping
+ *
+ */
/* We map both L3 and L4 on OMAP2 */
#define L3_24XX_PHYS L3_24XX_BASE/* 0x6800 */
@@ -106,7 +114,11 @@
#define DSP_MMU_24XX_VIRT 0xe200
#define DSP_MMU_24XX_SIZE SZ_4K
-#elif defined(CONFIG_ARCH_OMAP3)
+/*
+ *
+ * Omap3 specific IO mapping
+ *
+ */
/* We map both L3 and L4 on OMAP3 */
#define L3_34XX_PHYS L3_34XX_BASE/* 0x6800 */
@@ -157,8 +169,12 @@
#define DSP_MMU_34XX_VIRT 0xe200
#define DSP_MMU_34XX_SIZE SZ_4K
+/*
+ *
+ * Omap4 specific IO mapping
+ *
+ */
-#elif defined(CONFIG_ARCH_OMAP4)
/* We map both L3 and L4 on OMAP4 */
#define L3_44XX_PHYS L3_44XX_BASE
#define L3_44XX_VIRT 0xd400
@@ -185,7 +201,12 @@
#define OMAP44XX_GPMC_VIRT 0xe000
#define OMAP44XX_GPMC_SIZE SZ_1M
-#endif
+
+/*
+ *
+ * Omap specific register access
+ *
+ */
#ifndef __ASSEMBLER__
diff --git a/arch/arm/plat-omap/io.c b/arch/arm/plat-omap/io.c
index d491ad1..b6defa2 100644
--- a/arch/arm/plat-omap/io.c
+++ b/arch/arm/plat-omap/io.c
@@ -30,8 +30,8 @@ void __iomem *omap_ioremap(unsigned long p, size_t size,
unsigned int type)
{
#ifdef CONFIG_ARCH_OMAP1
if (cpu_class_is_omap1()) {
- if (BETWEEN(p, IO_PHYS, IO_SIZE))
- return XLATE(p, IO_PHYS, IO_VIRT);
+ if (BETWEEN(p, OMAP1_IO_PHYS, OMAP1_IO_SIZE))
+ return XLATE(p, OMAP1_IO_PHYS, OMAP1_IO_VIRT);
}
if (cpu_is_omap730()) {
if (BETWEEN(p, OMAP730_DSP_BASE, OMAP730_DSP_SIZE))
--
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: PM: Remove duplicate code
Roger Quadros ext-roger.quad...@nokia.com writes: Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com Hmm, you don't think I need to be so careful as to do it twice. ;) I'll drop these duplicates when I rebase onto latest omap/master. Thanks, Kevin --- arch/arm/mach-omap2/pm34xx.c | 18 -- 1 files changed, 0 insertions(+), 18 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 7a4a525..d45295d 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -913,24 +913,6 @@ static void __init prcm_setup_regs(void) /* Clear any pending PRCM interrupts */ prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); - /* Don't attach IVA interrupts */ - prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL); - prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1); - prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3); - prm_write_mod_reg(0, OMAP3430_PER_MOD, OMAP3430_PM_IVAGRPSEL); - - /* Clear any pending 'reset' flags */ - prm_write_mod_reg(0x, MPU_MOD, RM_RSTST); - prm_write_mod_reg(0x, CORE_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_PER_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_EMU_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_NEON_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_DSS_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430ES2_USBHOST_MOD, RM_RSTST); - - /* Clear any pending PRCM interrupts */ - prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); - omap3_iva_idle(); omap3_d2d_idle(); } -- 1.6.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] ARM: OMAP: 3430SDP: Fix defconfig
From 50761c71479cf310313a733fe7bafda9af43e7a0 Mon Sep 17 00:00:00 2001 From: Sergio Aguirre saagui...@ti.com Date: Tue, 23 Jun 2009 10:55:28 -0500 Subject: [PATCH] ARM: OMAP: 3430SDP: Fix defconfig This patch makes the SDP boot again with the defconfig. Changes done: - Removes other selected boards. - Sets the Low Level debug output for UART1. - Disables some paripherals from other boards. Tested on a SDP3430-VE5.1.0 (OMAP3430 ES3.1) Signed-off-by: Sergio Aguirre saagui...@ti.com --- arch/arm/configs/omap_3430sdp_defconfig | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/arm/configs/omap_3430sdp_defconfig b/arch/arm/configs/omap_3430sdp_defconfig index 73e0128..8a4a7e2 100644 --- a/arch/arm/configs/omap_3430sdp_defconfig +++ b/arch/arm/configs/omap_3430sdp_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.29-rc8 -# Fri Mar 13 14:17:01 2009 +# Linux kernel version: 2.6.30-omap1 +# Tue Jun 23 10:36:45 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -197,9 +197,9 @@ CONFIG_OMAP_MCBSP=y CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_32K_TIMER_HZ=128 CONFIG_OMAP_DM_TIMER=y -# CONFIG_OMAP_LL_DEBUG_UART1 is not set +CONFIG_OMAP_LL_DEBUG_UART1=y # CONFIG_OMAP_LL_DEBUG_UART2 is not set -CONFIG_OMAP_LL_DEBUG_UART3=y +# CONFIG_OMAP_LL_DEBUG_UART3 is not set CONFIG_OMAP_SERIAL_WAKE=y CONFIG_ARCH_OMAP34XX=y CONFIG_ARCH_OMAP3430=y @@ -207,10 +207,10 @@ CONFIG_ARCH_OMAP3430=y # # OMAP Board Type # -CONFIG_MACH_OMAP3_BEAGLE=y -CONFIG_MACH_OMAP_LDP=y -CONFIG_MACH_OVERO=y -CONFIG_MACH_OMAP3_PANDORA=y +# CONFIG_MACH_OMAP3_BEAGLE is not set +# CONFIG_MACH_OMAP_LDP is not set +# CONFIG_MACH_OVERO is not set +# CONFIG_MACH_OMAP3_PANDORA is not set CONFIG_MACH_OMAP_3430SDP=y # @@ -950,7 +950,7 @@ CONFIG_SPI_OMAP24XX=y # CONFIG_SPI_TLE62X0 is not set CONFIG_ARCH_REQUIRE_GPIOLIB=y CONFIG_GPIOLIB=y -CONFIG_DEBUG_GPIO=y +# CONFIG_DEBUG_GPIO is not set CONFIG_GPIO_SYSFS=y # @@ -1405,7 +1405,7 @@ CONFIG_SND_OMAP_SOC=y CONFIG_SND_OMAP_SOC_MCBSP=y # CONFIG_SND_OMAP_SOC_OVERO is not set CONFIG_SND_OMAP_SOC_SDP3430=y -CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=y +# CONFIG_SND_OMAP_SOC_OMAP3_PANDORA is not set CONFIG_SND_SOC_I2C_AND_SPI=y # CONFIG_SND_SOC_ALL_CODECS is not set CONFIG_SND_SOC_TWL4030=y -- 1.6.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb otg changes break booting on omaps
On Tue, Jun 23, 2009 at 03:20:19PM +0200, ext Gupta, Ajay Kumar wrote: Looks like commit 84e250ffa76dddc1bad84e04248a27f442c25986 musb: proper hookup to transceiver drivers breaks booting on omaps if no transceiver is configured. Got any patches for that? Tony, Is this on OMAP35x EVM? If so then the below patch should help. http://marc.info/?l=linux-omapm=123907915211910w=2 and omap3x30-based hardware will most likely use twl4030-usb and in some cases (like evm) use the no-op trasceiver. -- balbi -- 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] i2c:OMAP3:Errata workaround for spurious RDR event
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, June 22, 2009 10:20 PM To: Pakaravoor, Jagadeesh Cc: Hald, Ulrik Bech; linux-omap@vger.kernel.org Subject: RE: [PATCH v2 1/1] i2c:OMAP3:Errata workaround for spurious RDR event Hello Jagadeesh, On Tue, 23 Jun 2009, Pakaravoor, Jagadeesh wrote: + u8 stat2 = 0; + stat2 = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); + if (stat2 OMAP_I2C_STAT_BB) + return IRQ_HANDLED; Why use stat2? Why not just test stat again? Stat is read at the beginning of the ISR, what if BB bit gets cleared/set a while later, not along with RDR, as a corner case? If that is possible, then the comment in this patch needs to be changed: + /* 3430 I2C Errata 1.15 + * RDR could be set when the bus is busy, then + * ignore the interrupt, and clear the bit. + */ This implies that the state of the BB bit is important when the RDR bit is set. The closest sample we have for that is the contents of the 'stat' variable. If I understand it correctly, you're concerned that the wording of the comment lets one think, that the state of the bus is critical at the moment the RDR interrupt is set? I guess you're right about that, since the wording could be a little misleading. The point of the errata workaround is only to prevent handling of the RDR interrupt, if the bus is busy at the time when the RDR is to be handled. It doesn't matter if BB has been set/cleared before that. So maybe, the wording of the comment should be: /* 3430 I2C Errata 1.15, 2430 I2C Errata 1.67: * RDR should not be handled when bus is busy */ ? If we keep it this way, re-reading the register; what could be the potential problem? It doesn't match the definition of the erratum as expressed in the comment. Is it possible for the RDR bit to be erroneously set when BB = 0? Yes, the nature of the errata is that the RDR interrupt could be spurious. Although, if the bus is not busy and the RDR is set erroneously (there are no bytes in the FIFO to be drained), then the normal isr code would just leave and do nothing, which is what we also need in the errata work around. - Paul /Ulrik -- 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] i2c:OMAP3:Errata workaround for spurious RDR event
Hello Ulrik, On Tue, 23 Jun 2009, Hald, Ulrik Bech wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, June 22, 2009 10:20 PM To: Pakaravoor, Jagadeesh Cc: Hald, Ulrik Bech; linux-omap@vger.kernel.org Subject: RE: [PATCH v2 1/1] i2c:OMAP3:Errata workaround for spurious RDR event Hello Jagadeesh, On Tue, 23 Jun 2009, Pakaravoor, Jagadeesh wrote: + u8 stat2 = 0; + stat2 = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); + if (stat2 OMAP_I2C_STAT_BB) + return IRQ_HANDLED; Why use stat2? Why not just test stat again? Stat is read at the beginning of the ISR, what if BB bit gets cleared/set a while later, not along with RDR, as a corner case? If that is possible, then the comment in this patch needs to be changed: + /* 3430 I2C Errata 1.15 + * RDR could be set when the bus is busy, then + * ignore the interrupt, and clear the bit. + */ This implies that the state of the BB bit is important when the RDR bit is set. The closest sample we have for that is the contents of the 'stat' variable. If I understand it correctly, you're concerned that the wording of the comment lets one think, that the state of the bus is critical at the moment the RDR interrupt is set? I guess you're right about that, since the wording could be a little misleading. My concern is that the comment and the code seem to conflict. The point of the errata workaround is only to prevent handling of the RDR interrupt, if the bus is busy at the time when the RDR is to be handled. It doesn't matter if BB has been set/cleared before that. So maybe, the wording of the comment should be: /* 3430 I2C Errata 1.15, 2430 I2C Errata 1.67: * RDR should not be handled when bus is busy */ ? Yes, that is better. If we keep it this way, re-reading the register; what could be the potential problem? It doesn't match the definition of the erratum as expressed in the comment. Is it possible for the RDR bit to be erroneously set when BB = 0? Yes, the nature of the errata is that the RDR interrupt could be spurious. Although, if the bus is not busy and the RDR is set erroneously (there are no bytes in the FIFO to be drained), then the normal isr code would just leave and do nothing, which is what we also need in the errata work around. Okay. So it looks like there is a unfixable race here. Is it possible for BB to be 0 during the stat2 read, then for BB to go to 1 immediately afterwards? Then the rest of the RDR handler would be entered. If this is possible, what will the ISR do -- will it hang? If this assessment of the problem is accurate, the stat2 read shrinks the race window, and then indeed seems useful. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH -pm 1/2] SDRC: check for stuck DLL state machine and kick
Hello Richard, On Fri, 19 Jun 2009, Woodruff, Richard wrote: From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, June 18, 2009 4:07 PM On Wed, 17 Jun 2009, Woodruff, Richard wrote: I've only seen the condition along side of very aggressive SDRC_POWER settings. Could you send over the SDRC_POWER settings that cause this problem? This is one pulled for a custom board: # ./readmem 0x6d70 0x000200AD Thanks. According to the 34xx TRM Table 11-178 this sets the following: (asterisks mark differences from the current linux-omap code base.) WAKEUPPROC = 0 * AUTOCOUNT = 0x200 * SRFRONRESET = 1 SRFRONIDLEREQ = 0 * CLKCTRL = 2 EXTCLKDIS = 1 PWDENA = 1 PAGEPOLICY = 1 Looks like the significant difference is the use of CLKCTRL = 0x2 (+ AUTOCOUNT). Maybe there is some SDRC bug related to CLKCTRL = 0x2 that causes this problem? Perhaps the problem is partially related to PWDENA = 1 and erratum 1.150? Anyway, will do a test run here with this SDRC_POWER register value and see if the problem reproduces. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/1] i2c:OMAP3:Errata workaround for spurious RDR event
Paul, Ulrik, Just adding my view to this discussion: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, June 23, 2009 9:05 PM To: Hald, Ulrik Bech Cc: Pakaravoor, Jagadeesh; linux-omap@vger.kernel.org Subject: RE: [PATCH v2 1/1] i2c:OMAP3:Errata workaround for spurious RDR event + u8 stat2 = 0; + stat2 = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); + if (stat2 OMAP_I2C_STAT_BB) + return IRQ_HANDLED; Why use stat2? Why not just test stat again? Stat is read at the beginning of the ISR, what if BB bit gets cleared/set a while later, not along with RDR, as a corner case? If that is possible, then the comment in this patch needs to be changed: + /* 3430 I2C Errata 1.15 + * RDR could be set when the bus is busy, then + * ignore the interrupt, and clear the bit. + */ This implies that the state of the BB bit is important when the RDR bit is set. The closest sample we have for that is the contents of the 'stat' variable. If I understand it correctly, you're concerned that the wording of the comment lets one think, that the state of the bus is critical at the moment the RDR interrupt is set? I guess you're right about that, since the wording could be a little misleading. My concern is that the comment and the code seem to conflict. The point of the errata workaround is only to prevent handling of the RDR interrupt, if the bus is busy at the time when the RDR is to be handled. It doesn't matter if BB has been set/cleared before that. So maybe, the wording of the comment should be: /* 3430 I2C Errata 1.15, 2430 I2C Errata 1.67: * RDR should not be handled when bus is busy */ ? Yes, that is better. If we keep it this way, re-reading the register; what could be the potential problem? It doesn't match the definition of the erratum as expressed in the comment. Is it possible for the RDR bit to be erroneously set when BB = 0? Yes, the nature of the errata is that the RDR interrupt could be spurious. Although, if the bus is not busy and the RDR is set erroneously (there are no bytes in the FIFO to be drained), then the normal isr code would just leave and do nothing, which is what we also need in the errata work around. Okay. So it looks like there is a unfixable race here. Is it possible for BB to be 0 during the stat2 read, then for BB to go to 1 immediately afterwards? Then the rest of the RDR handler would be entered. If this is possible, what will the ISR do -- will it hang? If this assessment of the problem is accurate, the stat2 read shrinks the race window, and then indeed seems useful. a) why would bus be busy? - answer bus is busy before a transaction starts - each transaction is an atomic operation. If someone goofs around with signal while a master is sending/receiving data, there is AL(Arbitration Lost).. not Bus busy. b) Look at the flow in TRM figure 18-13 I2C Master Reciever Mode, interrupt mode - where does BB get checked by the h/w? Not in the middle of the transaction.. Apologies if I am wrong, so am not entirely following the discussion here.. 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 v2 1/1] i2c:OMAP3:Errata workaround for spurious RDR event
On Tue, 23 Jun 2009, Paul Walmsley wrote: Okay. So it looks like there is a unfixable race here. Is it possible for BB to be 0 during the stat2 read, then for BB to go to 1 immediately afterwards? Then the rest of the RDR handler would be entered. If this is possible, what will the ISR do -- will it hang? By the way, it would also be helpful if you could check what the certain rare conditions are that erratum 1.15 refers to that cause this problem... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP clock/powerdomain/SDRC patches for post-2.6.30
Hello Jean, On Fri, 19 Jun 2009, Jean Pihet wrote: On Friday 19 June 2009 18:23:42 Russell King - ARM Linux wrote: On Thu, Jun 18, 2009 at 08:48:47AM +0300, Tony Lindgren wrote: Paul, can you please post a git pull request for Russell on these? I think these should still go in if possible. Russell, if you think it's too late, I'll pile them up into omap for-next branch. Let's merge them. Also, can you look at '[PATCH 0/2] Allows the SDRAM self refresh to work with 2 chip selects' which apply on top of Paul's SDRC patches? I'll merge these patches into the next SDRC series for Russell and Tony. thanks, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Can a phone hook switch follow alsa jack model?
On Tue, Jun 23, 2009 at 03:28:54PM +0200, Janusz Krzysztofik wrote: After my initial attempt to add support for the switch using gpio-keys driver, I am no longer sure if it is a good idea to follow the keyboard model, that the driver has been designed after, for driving a switch that has nothing to do with keyboards and may required a different approach. That approach was quite common in the past. However, I am not sure if the switch in question matches the alsa jack model closely enough. I see the switch usage not as simple as turning handset microphone/speaker on or off. It can be used for other purposes as well, like accepting a phone call or actually dialing a number that has been just typed in. Furthermore, it can be used to turn off a speakerphone function, while, in turn, the related handset microphone/speaker pair can be turned off not only with this switch, but with a handsfree button as well, for example. That can all be accomodated within the ASoC jack framework (I'm assuming you'll be doing an ASoC rather than generic ALSA driver). You get the input device just the same as you get with gpio-keys so you can do stuff in user space, the main difference is that you can also arrange for some of the power management within ASoC to be hooked up with the jack automatically as well. With what you're describing above I'd tie the mic and speaker in the headset to DAPM automatically. All that extra functionality looks like belonging to userspace rather then kernel, not like other alsa jack implementations that seem to do all the job of switching media paths inside the kernel. That is why I am not sure if the jack model is suitable for the purpose. The switching in kernel for ASoC should generally be confined to marking outputs as powered or unpowered - things like marking a headphone jack as disabled when there's nothing plugged in to it that can be done unconditionally. Everything else should get punted to user space. -- 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: musb otg changes break booting on omaps
On Tuesday 23 June 2009, Felipe Balbi wrote: Looks like commit 84e250ffa76dddc1bad84e04248a27f442c25986 musb: proper hookup to transceiver drivers breaks booting on omaps if no transceiver is configured. Got any patches for that? Tony, Is this on OMAP35x EVM? If so then the below patch should help. http://marc.info/?l=linux-omapm=123907915211910w=2 The problem with that patch is that the transceiver config is board-specific. So the omap2430.c change is wrong. Just register the NOP transceiver in the EVM setup code. and omap3x30-based hardware will most likely use twl4030-usb and in some cases (like evm) use the no-op trasceiver. I think I've got an SX51 patch somewhwere, I'll dig it up. - Dave -- 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/2] Support OMAP3 VC adaptation with different Power IC
From c1aba8ba7af3ddd16346d95795bda71e65baa4d0 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Wed, 24 Jun 2009 06:48:52 +0800
Subject: [PATCH] Support OMAP3 VC adaptation with different Power IC
Current OMAP SmartReflex driver only supports TI Triton
Power IC, add a callback to make it possible to use
different PowerIC and use different settings to
configure OMAP3 Voltage Controller for DVFS
Board file can setup a new function to have different settings
on SR to configure their Power IC for voltage scaling
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/mach-omap2/smartreflex.c | 13 +
arch/arm/mach-omap2/smartreflex.h |4
arch/arm/plat-omap/Kconfig|2 +-
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 9d462e3..bacf602 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -52,6 +52,8 @@ struct omap_sr {
#define SR_REGADDR(offs) (sr-srbase_addr + offset)
+static omap3_voltagescale_vcbypass_t omap3_volscale_vcbypass_fun;
+
static inline void sr_write_reg(struct omap_sr *sr, unsigned offset,
u32 value)
{
__raw_writel(value, SR_REGADDR(offset));
@@ -767,6 +769,11 @@ void disable_smartreflex(int srid)
}
}
+void omap3_voltagescale_vcbypass_setup(omap3_voltagescale_vcbypass_t
fun)
+{
+ omap3_volscale_vcbypass_fun = fun;
+}
+
/* Voltage Scaling using SR VCBYPASS */
int sr_voltagescale_vcbypass(u32 target_opp, u32 current_opp,
u8 target_vsel, u8 current_vsel)
@@ -779,6 +786,10 @@ int sr_voltagescale_vcbypass(u32 target_opp, u32
current_opp,
u32 t2_smps_steps = 0;
u32 t2_smps_delay = 0;
+ if (omap3_volscale_vcbypass_fun)
+ return omap3_volscale_vcbypass_fun(target_opp,
current_opp,
+ target_vsel,
current_vsel);
+
vdd = get_vdd(target_opp);
target_opp_no = get_opp_no(target_opp);
current_opp_no = get_opp_no(current_opp);
@@ -940,6 +951,7 @@ static int __init omap3_sr_init(void)
return -ENODEV;
}
+#ifdef CONFIG_TWL4030_CORE
/* Enable SR on T2 */
ret = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, RdReg,
R_DCDC_GLOBAL_CFG);
@@ -947,6 +959,7 @@ static int __init omap3_sr_init(void)
RdReg |= DCDC_GLOBAL_CFG_ENABLE_SRFLX;
ret |= twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, RdReg,
R_DCDC_GLOBAL_CFG);
+#endif
if (cpu_is_omap34xx()) {
sr1.clk = clk_get(NULL, sr1_fck);
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index 2a0e823..c4aca9d 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -248,9 +248,13 @@ void disable_smartreflex(int srid);
int sr_voltagescale_vcbypass(u32 t_opp, u32 c_opp, u8 t_vsel, u8
c_vsel);
void sr_start_vddautocomap(int srid, u32 target_opp_no);
int sr_stop_vddautocomap(int srid);
+typedef int (*omap3_voltagescale_vcbypass_t)(u32 t_opp, u32 c_opp,
+ u8 t_vsel, u8 c_vsel);
+void omap3_voltagescale_vcbypass_setup(omap3_voltagescale_vcbypass_t
fun);
#else
static inline void enable_smartreflex(int srid) {}
static inline void disable_smartreflex(int srid) {}
+#define omap3_voltagescale_vcbypass_setup(fun) do {} while (0);
#endif
#endif
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index c8ba1e2..8d2c607 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -68,7 +68,7 @@ config OMAP_DEBUG_CLOCKDOMAIN
config OMAP_SMARTREFLEX
bool SmartReflex support
- depends on ARCH_OMAP34XX TWL4030_CORE PM
+ depends on ARCH_OMAP34XX PM
help
Say Y if you want to enable SmartReflex.
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP3: Implement separate function to send bypass command through VC
From 803cbdcd8df3d6f931089979c2dbad8942512cb4 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Wed, 24 Jun 2009 07:57:17 +0800
Subject: [PATCH] OMAP3: Implement separate function to send bypass
command through VC
Some system may need use OMAP VC to configure their Power IC,
so make the common code to send bypass command using SR VC
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 36 ++
arch/arm/mach-omap2/smartreflex.c | 59
+++-
3 files changed, 42 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index ddc9453..fa118cd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -44,6 +44,7 @@ extern int set_pwrdm_state(struct powerdomain *pwrdm,
u32 state);
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int
state);
extern void omap3_set_prm_setup_vc(struct prm_setup_vc *setup_vc);
+extern int omap3_vc_bypass_cmd(u8 slave_addr, u8 reg_addr, u8 cmd);
#ifdef CONFIG_CPU_IDLE
int omap3_idle_init(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7a4a525..85b0944 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -26,6 +26,7 @@
#include linux/err.h
#include linux/gpio.h
#include linux/clk.h
+#include linux/delay.h
#include mach/sram.h
#include mach/prcm.h
@@ -1135,6 +1136,41 @@ err2:
return ret;
}
+/* Program Power IC via OMAP3 voltage controller bypass interface */
+int omap3_vc_bypass_cmd(u8 slave_addr, u8 reg_addr, u8 cmd)
+{
+ u32 vc_bypass_value;
+ u32 loop_cnt = 0, retries_cnt = 0;
+
+ vc_bypass_value = (cmd OMAP3430_DATA_SHIFT) |
+ (reg_addr OMAP3430_REGADDR_SHIFT) |
+ (slave_addr OMAP3430_SLAVEADDR_SHIFT);
+
+ prm_write_mod_reg(vc_bypass_value, OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+
+ vc_bypass_value = prm_set_mod_reg_bits(OMAP3430_VALID,
OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+
+ while ((vc_bypass_value OMAP3430_VALID) != 0x0) {
+ loop_cnt++;
+ if (retries_cnt 10) {
+ printk(KERN_ERRLoop count exceeded in check SR
I2C
+
write\n);
+ return 1;
+ }
+ if (loop_cnt 50) {
+ retries_cnt++;
+ loop_cnt = 0;
+ udelay(10);
+ }
+ vc_bypass_value = prm_read_mod_reg(OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+ }
+
+ return 0;
+}
+
static void __init configure_vc(void)
{
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index bacf602..2158b5c 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -35,6 +35,7 @@
#include prm.h
#include smartreflex.h
#include prm-regbits-34xx.h
+#include pm.h
struct omap_sr {
int srid;
@@ -449,8 +450,6 @@ static int sr_reset_voltage(int srid)
{
u32 target_opp_no, vsel = 0;
u32 reg_addr = 0;
- u32 loop_cnt = 0, retries_cnt = 0;
- u32 vc_bypass_value;
u32 t2_smps_steps = 0;
u32 t2_smps_delay = 0;
u32 prm_vp1_voltage, prm_vp2_voltage;
@@ -479,31 +478,8 @@ static int sr_reset_voltage(int srid)
t2_smps_steps = abs(vsel - prm_vp2_voltage);
}
- vc_bypass_value = (vsel OMAP3430_DATA_SHIFT) |
- (reg_addr OMAP3430_REGADDR_SHIFT) |
- (R_SRI2C_SLAVE_ADDR
OMAP3430_SLAVEADDR_SHIFT);
-
- prm_write_mod_reg(vc_bypass_value, OMAP3430_GR_MOD,
- OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
-
- vc_bypass_value = prm_set_mod_reg_bits(OMAP3430_VALID,
OMAP3430_GR_MOD,
- OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
-
- while ((vc_bypass_value OMAP3430_VALID) != 0x0) {
- loop_cnt++;
- if (retries_cnt 10) {
- pr_info(Loop count exceeded in check SR I2C
-
write\n);
- return 1;
- }
- if (loop_cnt 50) {
- retries_cnt++;
- loop_cnt = 0;
- udelay(10);
- }
- vc_bypass_value = prm_read_mod_reg(OMAP3430_GR_MOD,
- OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
- }
+ if (omap3_vc_bypass_cmd(R_SRI2C_SLAVE_ADDR, reg_addr, vsel))
+ return 1;
/*
* T2 SMPS slew rate (min) 4mV/uS, step size 12.5mV,
@@ -780,9 +756,7 @@ int sr_voltagescale_vcbypass(u32 target_opp, u32
current_opp,
Re: [PATCH 1/2] Support OMAP3 VC adaptation with different Power IC
Wang Sawsd-A24013 cqw...@motorola.com writes:
From c1aba8ba7af3ddd16346d95795bda71e65baa4d0 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Wed, 24 Jun 2009 06:48:52 +0800
Subject: [PATCH] Support OMAP3 VC adaptation with different Power IC
Current OMAP SmartReflex driver only supports TI Triton
Power IC, add a callback to make it possible to use
different PowerIC and use different settings to
configure OMAP3 Voltage Controller for DVFS
Board file can setup a new function to have different settings
on SR to configure their Power IC for voltage scaling
Signed-off-by: Chunqiu Wang cqw...@motorola.com
Your patch seems wrapped again:
checkpatch reports:
ERROR: patch seems to be corrupt (line wrapped?)
#38: FILE: arch/arm/mach-omap2/smartreflex.c:57:
u32 value)
ERROR: trailing whitespace
#95: FILE: arch/arm/mach-omap2/smartreflex.h:252:
+^I^I^I^I^I^Iu8 t_vsel, u8 c_vsel); $
total: 2 errors, 0 warnings, 71 lines checked
---
arch/arm/mach-omap2/smartreflex.c | 13 +
arch/arm/mach-omap2/smartreflex.h |4
arch/arm/plat-omap/Kconfig|2 +-
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 9d462e3..bacf602 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -52,6 +52,8 @@ struct omap_sr {
#define SR_REGADDR(offs) (sr-srbase_addr + offset)
+static omap3_voltagescale_vcbypass_t omap3_volscale_vcbypass_fun;
+
static inline void sr_write_reg(struct omap_sr *sr, unsigned offset,
u32 value)
{
__raw_writel(value, SR_REGADDR(offset));
@@ -767,6 +769,11 @@ void disable_smartreflex(int srid)
}
}
+void omap3_voltagescale_vcbypass_setup(omap3_voltagescale_vcbypass_t
fun)
+{
+ omap3_volscale_vcbypass_fun = fun;
+}
+
/* Voltage Scaling using SR VCBYPASS */
int sr_voltagescale_vcbypass(u32 target_opp, u32 current_opp,
u8 target_vsel, u8 current_vsel)
@@ -779,6 +786,10 @@ int sr_voltagescale_vcbypass(u32 target_opp, u32
current_opp,
u32 t2_smps_steps = 0;
u32 t2_smps_delay = 0;
+ if (omap3_volscale_vcbypass_fun)
+ return omap3_volscale_vcbypass_fun(target_opp,
current_opp,
+ target_vsel,
current_vsel);
+
vdd = get_vdd(target_opp);
target_opp_no = get_opp_no(target_opp);
current_opp_no = get_opp_no(current_opp);
@@ -940,6 +951,7 @@ static int __init omap3_sr_init(void)
return -ENODEV;
}
+#ifdef CONFIG_TWL4030_CORE
/* Enable SR on T2 */
ret = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, RdReg,
R_DCDC_GLOBAL_CFG);
@@ -947,6 +959,7 @@ static int __init omap3_sr_init(void)
RdReg |= DCDC_GLOBAL_CFG_ENABLE_SRFLX;
ret |= twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, RdReg,
R_DCDC_GLOBAL_CFG);
+#endif
if (cpu_is_omap34xx()) {
sr1.clk = clk_get(NULL, sr1_fck);
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index 2a0e823..c4aca9d 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -248,9 +248,13 @@ void disable_smartreflex(int srid);
int sr_voltagescale_vcbypass(u32 t_opp, u32 c_opp, u8 t_vsel, u8
c_vsel);
void sr_start_vddautocomap(int srid, u32 target_opp_no);
int sr_stop_vddautocomap(int srid);
+typedef int (*omap3_voltagescale_vcbypass_t)(u32 t_opp, u32 c_opp,
+ u8 t_vsel, u8 c_vsel);
+void omap3_voltagescale_vcbypass_setup(omap3_voltagescale_vcbypass_t
fun);
#else
static inline void enable_smartreflex(int srid) {}
static inline void disable_smartreflex(int srid) {}
+#define omap3_voltagescale_vcbypass_setup(fun) do {} while (0);
#endif
#endif
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index c8ba1e2..8d2c607 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -68,7 +68,7 @@ config OMAP_DEBUG_CLOCKDOMAIN
config OMAP_SMARTREFLEX
bool SmartReflex support
- depends on ARCH_OMAP34XX TWL4030_CORE PM
+ depends on ARCH_OMAP34XX PM
help
Say Y if you want to enable SmartReflex.
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] OMAP3: PM: reset USB OTG module on boot
Rather than simply setting force-idle mode on boot, do a reset of the
OTG module. This really ensures that any bootloader/bootstrap code
that leaves it active will not prevent future retention. After reset,
OTG module will be in force-idle, force-standby mode.
In addition, ensure that the iclk is enabled before attempting a write
to the module SYSCONFIG register.
Problem reported by Mike Chan mikec...@google.com
Tested-by: Mike Chan mikec...@google.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
If no comments/issues, this will be applied to PM branch and
backported to pm-2.6.29.
arch/arm/mach-omap2/usb-musb.c | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index d85296d..85731b8 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -32,12 +32,27 @@
#include mach/usb.h
#define OTG_SYSCONFIG (OMAP34XX_HSUSB_OTG_BASE + 0x404)
+#define OTG_SYSC_SOFTRESET BIT(1)
static void __init usb_musb_pm_init(void)
{
- /* Ensure force-idle mode for OTG controller */
- if (cpu_is_omap34xx())
- omap_writel(0, OTG_SYSCONFIG);
+ struct clk *iclk;
+
+ if (!cpu_is_omap34xx())
+ return;
+
+ iclk = clk_get(NULL, hsotgusb_ick);
+ if (WARN_ON(!iclk))
+ return;
+
+ clk_enable(iclk);
+
+ /* Reset OTG controller. After reset, it will be in
+* force-idle, force-standby mode. */
+ omap_writel(OTG_SYSC_SOFTRESET, OTG_SYSCONFIG);
+
+ clk_disable(iclk);
+ clk_put(iclk);
}
#ifdef CONFIG_USB_MUSB_SOC
--
1.6.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ARM][OMAP] TWL4030 IRQ
Russell,
After digging a bit, the proposed twl_irq change would need some major changes.
1. All the T2(TWL)drivers ( rtc, madc, bci, gpio, keypad, usb, mmc)needs
modification. Currently twl_irq fw implements kind of twl4030_irq_chip which
allows all the T2 drivers to get virtual interrupt numbers and can make use of
standard request_irq linux api.
2.Above also helps to have useful entries like /proc/interrupts/rtc etc. With
proposed change this also won't be available.
3. Register/unregister irq handlers to T2 from all the drivers
On the reported lock-up issue, I tried alternative to call mask/unmask
functions with disabling local cpu interrupts. This worked for me but not sure
whether it is entirely correct.
Something like this:
static void handle_twl4030_pih(unsigned int irq, irq_desc_t *desc)
{
+ unsigned long flags;
+
/* Acknowledge, clear *AND* mask the interrupt... */
+ local_irq_save(flags);
desc-chip-ack(irq);
+ local_irq_restore(flags);
complete(irq_event);
}
Do you think above approach is fine to get around the spin-lock lockup issue ?
-Original Message-
From: Shilimkar, Santosh
Sent: Saturday, June 20, 2009 8:55 PM
To: 'Tony Lindgren'; 'linux-omap@vger.kernel.org'
Cc: 'Russell King - ARM Linux'
Subject: [ARM][OMAP] TWL4030 IRQ
Just to brief you all, I came across a dead lock scenario on
the arm-smp kernel. After discussing with Russell on mailing
list, the actual bug seems be located in twl4030 IRQ implementation.
Initially I was suspecting the arm-generic area and hence
didn't include linux-omap list in the mail thread
For more information on this issue, please read this email thread.
http://marc.info/?l=linux-arm-kernelm=124550947525299w=2
I will create a patch for twl4030 and also would be
correcting upcoming twl6030 accordingly.
If anyone on this mailing list has any other opinion, please
react to the email thread.
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
