arch/arm/mach-omap* organization
Is there a reason why omap2, omap3, and now omap4 files are all packed into the mach-omap2 directory? It seems like it would make more sense for each omap version to have it's own directory. -Ben Goska -- 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: Question about tput constraint on zoom2 camera
Paul Walmsley wrote: Hello Dominic, On Sun, 2 Aug 2009, Curran, Dominic wrote: From: Paul Walmsley [p...@pwsan.com] Sent: Saturday, August 01, 2009 9:57 PM On Fri, 31 Jul 2009, Curran, Dominic wrote: I have been testing the zoom2 camera streaming while using different OPP's. Following table provides summary of what OPP's caused to happen: Streaming Vdd1(OPP)Vdd2(OPP) P/F VGA @ 30fps 12 Pass 8MP @ 7.5fps 12 Fails (stop streaming) 8MP @ 7.5fps 13 Pass So table shows that locking Vdd2 to OPP=3 when streaming 8MPixel works, but at OPP=2 then streaming fails (stops). So I thought the tput constraint made the most sense for camera. The Zoom2 camera sensor has a max tput of: 3280 x 2464 x 2bpp x 7.5fps = 121228800 bytes/s = 118387 KB/s However, this calculated value doesn't constrain Vdd2 to OPP3 (DVFS enabled). Experimentation shows that a tput value of 35 KB/s is required to constrain Vdd2 to OPP=3. Can you explain why the practical tput constraint is so much greater than the theoretical value ? Probably it is mostly due to two reasons: 1. most other L3 initiator drivers (eg., for DSS, SDMA, USB, etc) don't currently set bus throughput constraints, so we aren't currently adding in their interconnect usage; and 2. the interconnect throughput model in omap-pm-srf.c is optimistic. A couple of questions for you: (please forgive my ignorance of the camera subsystem): A. What other L3 initiators are active during the test? Presumably DSS, MPU? IVA2? B. I am assuming you are using the CCP2. What do you have CCP2_CTRL.BURST set to? This could impact interconnect utilization. - Paul Hi Paul No DSS (i'm just printing a '.' when i dequeue a frame). No IVA2. No per pixel processing by the ARM. I was trying to keep me testing as simple as possible. HOWEVER, your questions have made me think of something else which i think _may_ explain everything. The camera pipe should look like this: Sensor --> CSI2 Receiver --> CCDC --> PREVIEWER --> RESIZER --> MEM But because of a hardware bug, data has to be written to memory by Previewer and then read by Resizer. Thus a 'workaround' buffer is allocated for this purpose. Its not pretty but its the only way we can have Preview & Resizer in the pipe at the same time. So the pipeline actually looks like this: Sensor --> CSI2 Receiver --> CCDC --> PREVIEWER --> Workaround MEM --> RESIZER --> MEM Thus in order to get a single pixel through the pipe there has to be three L3 operations: 1) Write to workaround mem 2) Read from workaround mem 3) Write to final memory This seems to me like it actually increases the tput by 3x. 118387 KB/s x 3 = 355161 KB/s Which looks like it is very close to the number I found in practice (35). Does this seem like a reasonable explanation to you ? It does indeed. Thanks for the explanation of the ISP pipelines. Dominic, Please be sure to update the changelog in your patch to describe the pipeline and workaround mem which leads to your tput number. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] I2C: OMAP3: PM: (re)init for every transfer to support off-mode
Ben Dooks wrote:
On Tue, Jul 21, 2009 at 04:09:03PM -0700, Kevin Hilman wrote:
From: Rajendra Nayak
Because of OMAP off-mode, powerdomain can go off when I2C is idle.
Save enough state, and do a re-init for each transfer.
Additional save/restore state added by Jagadeesh Bhaskar Pakaravoor
(SYSC_REG) and Aaro Koskinen (wakeup sources.)
Also, The OMAP3430 TRM states:
"During active mode (I2Ci.I2C_CON[15] I2C_EN bit is set to 1), make no
changes to the I2Ci.I2C_SCLL and I2Ci.I2C_SCLH registers. Changes may
result in unpredictable behavior."
Hence, the I2C_EN bit should be clearer when modifying these
registers. Please note that clearing the entire I2C_CON register to
disable the I2C module is safe, because the I2C_CON register is
re-configured for each transfer.
should this be applied as a bugfix, or kept for next merge window?
next merge window is fine.
Thanks,
Kevin
Signed-off-by: Jouni Hogander
Signed-off-by: Rajendra Nayak
Cc: Jagadeesh Bhaskar Pakaravoor
Cc: Aaro Koskinen
Cc: Jon Hunter
Cc: Hu Tao
Cc: Xiaolong Chen
Signed-off-by: Kevin Hilman
---
This patch has been tested extensively as part of the OMAP 'PM branch'
drivers/i2c/busses/i2c-omap.c | 64 ++--
1 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ad8d201..bb8ae50 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -178,6 +178,12 @@ struct omap_i2c_dev {
unsignedb_hw:1; /* bad h/w fixes */
unsignedidle:1;
u16 iestate;/* Saved interrupt register */
+ u16 pscstate;
+ u16 scllstate;
+ u16 sclhstate;
+ u16 bufstate;
+ u16 syscstate;
+ u16 westate;
};
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -230,9 +236,18 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
clk_enable(dev->iclk);
clk_enable(dev->fclk);
+ if (cpu_is_omap34xx()) {
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev->bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev->syscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
dev->idle = 0;
- if (dev->iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
}
static void omap_i2c_idle(struct omap_i2c_dev *dev)
@@ -258,7 +273,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0;
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -287,24 +302,22 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
SYSC_AUTOIDLE_MASK);
} else if (dev->rev >= OMAP_I2C_REV_ON_3430) {
- u32 v;
-
- v = SYSC_AUTOIDLE_MASK;
- v |= SYSC_ENAWAKEUP_MASK;
- v |= (SYSC_IDLEMODE_SMART <<
+ dev->syscstate = SYSC_AUTOIDLE_MASK;
+ dev->syscstate |= SYSC_ENAWAKEUP_MASK;
+ dev->syscstate |= (SYSC_IDLEMODE_SMART <<
__ffs(SYSC_SIDLEMODE_MASK));
- v |= (SYSC_CLOCKACTIVITY_FCLK <<
+ dev->syscstate |= (SYSC_CLOCKACTIVITY_FCLK <<
__ffs(SYSC_CLOCKACTIVITY_MASK));
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, v);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
+ dev->syscstate);
/*
* Enabling all wakup sources to stop I2C freezing on
* WFI instruction.
* REVISIT: Some wkup sources might not be needed.
*/
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- OMAP_I2C_WE_ALL);
-
+ dev->westate = OMAP_I2C_WE_ALL;
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
}
}
omap_i2c_write_reg(dev, OMAP_I2C
Re: Enabling TPS65950 / TWL4030 Real-time clock functions
Hi Cliff, Yes, that looks good! It might just work! Best regards, Elvis On Aug 3, 2009, at 11:34 PM, Cliff Brake wrote: On Sat, Aug 1, 2009 at 9:56 AM, Elvis Dowson wrote: Hi, I am using a Gumstix Overo Earth (TI OMAP 3503) and this has a TPS69590/TWL4030 module, which I understand has a real-time clock subsystem. Is there support in the linux 2.6.29 or 2.6.31 kernel for enabling the RTC functions? I would like to preserve the system data and time between reboots. I've seen a 32Khz RTC clock option in the linux kernel. Is there a separate pin for a small battery just to keep supplying power to the RTC module? It looks like VBACKUP can probably be used for this. It will power the RTC rail if the main battery goes down. Will this work for you? Cliff -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Monday, August 03, 2009 2:36 AM
> To: Sonasath, Moiz
> Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Menon,
> Nishanth; Pandita, Vikram
> Subject: Re: [PATCH 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153
>
> Hello Moiz,
>
> A few remaining comments, most of these from an earlier message.
>
> On Tue, 21 Jul 2009, Sonasath, Moiz wrote:
>
> > When an XRDY/XDR is hit, wait for XUDF before writing data to DATA_REG.
> > Otherwise some data bytes can be lost while transferring them from the
> > memory to the I2C interface.
> >
> > Do a Busy-wait for XUDF, before writing data to DATA_REG. While waiting
> > if there is NACK | AL, set the appropriate error flags, ack the pending
> > interrupts and return from the ISR.
> >
> > Signed-off-by: Moiz Sonasath
> > Signed-off-by: Vikram pandita
> > ---
> > drivers/i2c/busses/i2c-omap.c | 24 +++-
> > 1 files changed, 23 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-
> omap.c
> > index 05b5e4c..8deaf87 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -672,9 +672,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
> > break;
> > }
> >
> > + err = 0;
> > +complete:
> > omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
> >
> > - err = 0;
> > if (stat & OMAP_I2C_STAT_NACK) {
> > err |= OMAP_I2C_STAT_NACK;
> > omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
> > @@ -764,6 +765,27 @@ omap_i2c_isr(int this_irq, void *dev_id)
> > "data to send\n");
> > break;
> > }
> > +
> > + /*
> > +* OMAP3430 Errata 1.153: When an XRDY/XDR
> > +* is hit, wait for XUDF before writing data
> > +* to DATA_REG. Otherwise some data bytes can
> > +* be lost while transferring them from the
> > +* memory to the I2C interface.
> > +*/
>
> Based on this description, shouldn't this patch also zero the transmit
> FIFO threshold? Consider what the transmit path becomes after this patch:
>
> 1. Fill transmit FIFO
> 2. Leave ISR & wait for interrupt
> 3. Interrupt happens due to XDR/XRDY (transmit FIFO low-water-mark
>reached)
> 4. Busy-wait until transmit FIFO & shift register completely empty
> 5. If more data to send, go to step #1
>
> i2c-omap.c currently sets the transmit FIFO threshold to 1/2 of the total
> FIFO size[1]. This means that, in the worst case, I2C3, the I2C ISR will
> busy-wait in step 4 for the time it takes 32 bytes to be transmitted.
> This is time that the MPU spends doing nothing but spinning, wasting
> power. This seems unnecessary and wasteful. The time the driver spends
> busy-waiting in the ISR should be reduced to the lowest possible duration.
>
> To do this, what I suggest that you additionally do in the patch is to
> reduce the transit FIFO threshold/low-water-mark, controlled by
> I2C_BUF.XTRSH, to the lowest possible value. This should maximize the
> time spent between steps 2 and 3 and minimize the time spent between steps
> 3 and 5.
>
> Is there a reason why this can't be done?
Yes, this is actually lined up in my list of actions. I will be working on this
to test the functionality and stability of I2C code with the threshold set to
zero.
>
> > +
> > + if (cpu_is_omap34xx()) {
>
> Does this erratum apply to the I2C IP block on OMAP2430? It also has FIFO
> transmit capability. It would be ideal if you can find out from the I2C
> IP block designers. If you cannot, please consider adding a comment that
> this may also apply to the I2C block on OMAP2430.
>
> In general it is best to enable these workarounds based on the I2C IP
> block's own revision register contents, not the OMAP CPU type. The goal
> is to remove all these OMAP-specific "cpu_is_omap()" macros from
> device drivers. For example, what if a future DaVinci part uses the same
> I2C IP block?
Yes this is the right way.
I am checking with the IP team and will get back on this action item.
>
> > + while (!(stat &
> > OMAP_I2C_STAT_XUDF)) {
>
> Is there a reason why you can't just reuse the main while() loop in the
> ISR, and add a state variable to handle any special casing needed in this
> context? That will avoid this separate while() loop.
>
The problem with using the main while() loop is the counter 'count' associated
with it as I am not sure if the count value of 100 is enough wait time for
allowing the XUDF bit to set and if we can come up with an accurate wait count
to be use
Re: Enabling TPS65950 / TWL4030 Real-time clock functions
On Sat, Aug 1, 2009 at 9:56 AM, Elvis Dowson wrote: > Hi, > I am using a Gumstix Overo Earth (TI OMAP 3503) and this has a > TPS69590/TWL4030 module, which I understand has a real-time clock subsystem. > > Is there support in the linux 2.6.29 or 2.6.31 kernel for enabling the RTC > functions? I would like to preserve the system data and time between > reboots. I've seen a 32Khz RTC clock option in the linux kernel. > > Is there a separate pin for a small battery just to keep supplying power to > the RTC module? It looks like VBACKUP can probably be used for this. It will power the RTC rail if the main battery goes down. Will this work for you? Cliff -- 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: drivers that require headers in mach-omap
Thanks for the input guys, Another case (currently not in omap-linux), if when the ohci-omap.c driver needs to check, val = cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD, CM_IDLEST) if (val & OMAP3430ES2_ST_USBHOST_STDBY_MASK) when putting the ohci bus into suspend (which I don't think the current ohci-omap.c currently supports) currently we just have a platform_data callback into the board file, but this really feels like omap specific and would be silly for every board file to implement this if they wanted ohci bus suspend. -- Mike On Mon, Aug 3, 2009 at 3:49 AM, Lohithakshan, Ranjith wrote: > > >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley >> Sent: Monday, August 03, 2009 5:04 AM >> To: Pandita, Vikram >> Cc: Mike Chan; Kevin Hilman; linux-omap@vger.kernel.org >> Subject: RE: drivers that require headers in mach-omap >> >> On Fri, 31 Jul 2009, Pandita, Vikram wrote: >> >> > >-Original Message- >> > >From: Mike Chan [mailto:m...@android.com] >> > >Sent: Thursday, July 30, 2009 6:20 PM >> > >To: Pandita, Vikram >> > >Cc: Kevin Hilman; linux-omap@vger.kernel.org >> > >Subject: Re: drivers that require headers in mach-omap >> > > >> > >On Thu, Jul 30, 2009 at 8:44 AM, Pandita, >> Vikram wrote: >> > >> >> > >>>-Original Message- >> > >>>From: linux-omap-ow...@vger.kernel.org >> > >>>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Mike Chan >> > >>>Sent: Tuesday, July 28, 2009 8:49 PM >> > >>>To: Kevin Hilman; linux-omap@vger.kernel.org >> > >>>Subject: drivers that require headers in mach-omap >> > >>> >> > >>>Omap folks, how are drivers that require access to prm and cm >> > >>>registers via cm_read_mod_reg() etc... suppose to access these? >> > >>> >> > >>>For example if drivers/usb/host/ohci-omap.c wanted to call: >> > >>>cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD, CM_IDLEST); >> > >> >> > >> The design was supposed to encapsulate the PRCM API's >> from drivers. >> > >> Driver has control over the iclk and fclk and the clock >> framework >> > >> would take care of any CM/PRM >> > >register settings. >> > >> >> > >> Accessing these registers in drivers would make the >> driver non-compatible for non-omap platforms. >> > >> >> > > >> > >Are drivers such as >> > > >> > >drivers/usb/host/ohci-omap.c >> > >drivers/usb/musb/omap2430.c >> > > >> > >suppose to be compatible for non-omap platforms? >> > >> > As you put it, no they are not. >> > All PRM/CM register accesses have been restricted to >> mach-omap2/plat-omap parts till now. >> > The question to ask is, what functionality is missing on >> enabling say the usbhost clock that clock framework is not >> doing, that driver has a need to do. >> >> Just to follow up on this: the plan should be to remove all >> PRM and CM references from those drivers. Some of those can >> be replaced with clock framework calls, others may need >> platform_data function pointers. > > To add to the list, drivers/usb/host/ehci-omap.c need a similar re-work. At > the moment, > it does some amount of DPLL5 programming in itself before enabling the iclk > and fclk. > >> >> >> - 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 >> >> -- 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: VDD2 setting question
Koen, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Koen Kooi > Sent: Monday, August 03, 2009 9:49 AM > To: Linux OMAP Users > Subject: VDD2 setting question > I'm to trying to lower VDD2 on beagleboard to something slightly below > 1V instead of the current slightly above 1V setting, but I'm having a VDD2 is tied to OMAP voltage, am I right? OPP2 and OPP3 are respectively at 1.15 and 1.06 or there abouts if I am not wrong -> since VDD2 essentially drives core domain (including L3 and SDRAM as a result), you really don't want to move the voltage lower without considering the implications. Smartreflex is the guy who can measure various points on OMAP and decide if the voltage can safely be lowered without impacting device behavior. > hard time figuring out how to do that in the linux-omap (non-PM) tree. > I grepped in (admittedly 2.6.29) arch/arm/mach-omap2 and it only > returned hits that seem to be related to smartreflex. Now, enabling If you still insist on doing this, see arch/arm/mach-omap2/omap3-opp.h > And the most important question: > > o Would a patch to lower the default value of VDD2 be accepted into > the tree? Can it be lowered globally or should it be guarded with an > machine_is_omap3beagle() clause? I don't think this is even valid. 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: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
CCing Jesslyn Abdul Salam Hope he has one osk. On Mon, Aug 3, 2009 at 10:53 AM, Arun KS wrote: > > > On Mon, Aug 3, 2009 at 7:00 AM, Janusz Krzysztofik > wrote: >> >> Jarkko Nikula wrote: >>> >>> On Mon, 3 Aug 2009 03:32:04 +0200 >>> Janusz Krzysztofik wrote: >>> This patch tries to correct the problem of full duplex mode not working over a single McBSP based CPU DAI. Created against linux-2.6.31-rc5. Tested on Amstrad Delta. >>> Do you have some specific test case how to trigger this? I haven't >>> seen this on 2420 or 34xx (e.g. with 'arecord -d 1 -f dat |aplay') but >>> I have no doubt that this can happen on 1510. At least this doesn't >>> cause any harm on Beagle so I'm fine with the fix. >> >> Hi, >> I made more testing on my OMAP1510 and found out that I could get your >> example usage working without my patch, but only if started like this: >> >> arecord -D hw:0,0 -f S16_LE|aplay -D hw:0,0 >> >> If I start the same with "-D hw:0,0" omitted from aplay, it doesn't work any >> longer, waiting forever. It definitelly doesn't work if I start capture and >> playback one after another, no matter which one goes first (record while >> playing or play while recording). So it looks like starting both streams >> simultaneously can do the job, but a short delay breaks it. >> >> With my patch, it seems to work fine for me in all cases. >> >> Jarkko, have you ever tried it on your OMAP2/3 with parallel playback and >> capture started one after another, not simultaneously? >> >> Arun, can your snd-soc-osk9512 work on OMAP1610 in full duplex mode without >> any limitations? > > > Janusz, > > Haven't done testing in full duplex mode. > I don't have access to osk5912 board now. If someone has got osk and do the > testing it ll be good. It ll take at least another 2 more month for me to do > the testing on osk. > > Regards, > Arun > >> >> >> If the problem appears to be OMAP1510 or AMS_DELTA specific, I can add a >> check for a machine or cpu type to avoid braking unaffected machines. >> >> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: TWL4030 IRQ
On Mon, Aug 03, 2009 at 06:36:12PM +0200, Samuel Ortiz wrote: > Hi Santosh, > > On Mon, Jul 27, 2009 at 11:30:48AM +0530, Santosh Shilimkar wrote: > > From: Russell King > > > > (Rebased on 2.6.31-rc4) > > > > The TWL4030 IRQ handler has a bug which leads to spinlock lock-up. It is > > calling the 'unmask' function in a process context. :The mask/unmask/ack > > functions are only designed to be called from the IRQ handler code, > > or the proper API interfaces found in linux/interrupt.h. > > > > Also there is no need to have IRQ chaining mechanism. The right way to > > handle this is to claim the parent interrupt as a standard interrupt > > and arrange for handle_twl4030_pih to take care of the rest of the devices. > I'd like this one to be split in 2 different patches as you're addressing 2 > different issues here. You'd like me to remove the IRQ handling entirely from this code as one patch, thereby breaking it, and then add the new IRQ handling as a separate patch? Are you sure? I really don't think so, and I suspect you haven't even read the patch. It's all _one_ issue, with two explainations of why the current code is wrong. So my reply is: unable to split patch. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: TWL4030 IRQ
Hi Santosh,
On Mon, Jul 27, 2009 at 11:30:48AM +0530, Santosh Shilimkar wrote:
> From: Russell King
>
> (Rebased on 2.6.31-rc4)
>
> The TWL4030 IRQ handler has a bug which leads to spinlock lock-up. It is
> calling the 'unmask' function in a process context. :The mask/unmask/ack
> functions are only designed to be called from the IRQ handler code,
> or the proper API interfaces found in linux/interrupt.h.
>
> Also there is no need to have IRQ chaining mechanism. The right way to
> handle this is to claim the parent interrupt as a standard interrupt
> and arrange for handle_twl4030_pih to take care of the rest of the devices.
I'd like this one to be split in 2 different patches as you're addressing 2
different issues here.
Cheers,
Samuel.
> Mail thread on this issue can be found at:
> http://marc.info/?l=linux-arm-kernel&m=124629940123396&w=2
>
> Signed-off-by: Russell King
> Tested-by: Santosh Shilimkar
> ---
> drivers/mfd/twl4030-irq.c | 55 +++-
> 1 files changed, 24 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
> index bae61b2..7d43083 100644
> --- a/drivers/mfd/twl4030-irq.c
> +++ b/drivers/mfd/twl4030-irq.c
> @@ -180,14 +180,9 @@ static struct completion irq_event;
> static int twl4030_irq_thread(void *data)
> {
> long irq = (long)data;
> - struct irq_desc *desc = irq_to_desc(irq);
> static unsigned i2c_errors;
> static const unsigned max_i2c_errors = 100;
>
> - if (!desc) {
> - pr_err("twl4030: Invalid IRQ: %ld\n", irq);
> - return -EINVAL;
> - }
>
> current->flags |= PF_NOFREEZE;
>
> @@ -240,7 +235,7 @@ static int twl4030_irq_thread(void *data)
> }
> local_irq_enable();
>
> - desc->chip->unmask(irq);
> + enable_irq(irq);
> }
>
> return 0;
> @@ -255,25 +250,13 @@ static int twl4030_irq_thread(void *data)
> * thread. All we do here is acknowledge and mask the interrupt and wakeup
> * the kernel thread.
> */
> -static void handle_twl4030_pih(unsigned int irq, struct irq_desc *desc)
> +static irqreturn_t handle_twl4030_pih(int irq, void *devid)
> {
> /* Acknowledge, clear *AND* mask the interrupt... */
> - desc->chip->ack(irq);
> - complete(&irq_event);
> -}
> -
> -static struct task_struct *start_twl4030_irq_thread(long irq)
> -{
> - struct task_struct *thread;
> -
> - init_completion(&irq_event);
> - thread = kthread_run(twl4030_irq_thread, (void *)irq, "twl4030-irq");
> - if (!thread)
> - pr_err("twl4030: could not create irq %ld thread!\n", irq);
> -
> - return thread;
> + disable_irq_nosync(irq);
> + complete(devid);
> + return IRQ_HANDLED;
> }
> -
> /*--*/
>
> /*
> @@ -734,18 +717,28 @@ int twl_init_irq(int irq_num, unsigned irq_base,
> unsigned irq_end)
> }
>
> /* install an irq handler to demultiplex the TWL4030 interrupt */
> - task = start_twl4030_irq_thread(irq_num);
> - if (!task) {
> - pr_err("twl4030: irq thread FAIL\n");
> - status = -ESRCH;
> - goto fail;
> - }
>
> - set_irq_data(irq_num, task);
> - set_irq_chained_handler(irq_num, handle_twl4030_pih);
>
> - return status;
> + init_completion(&irq_event);
>
> + status = request_irq(irq_num, handle_twl4030_pih, IRQF_DISABLED,
> + "TWL4030-PIH", &irq_event);
> + if (status < 0) {
> + pr_err("twl4030: could not claim irq%d: %d\n", irq_num, status);
> + goto fail_rqirq;
> + }
> +
> + task = kthread_run(twl4030_irq_thread, (void *)irq_num, "twl4030-irq");
> + if (IS_ERR(task)) {
> + pr_err("twl4030: could not create irq %d thread!\n", irq_num);
> + status = PTR_ERR(task);
> + goto fail_kthread;
> + }
> + return status;
> +fail_kthread:
> + free_irq(irq_num, &irq_event);
> +fail_rqirq:
> + /* clean up twl4030_sih_setup */
> fail:
> for (i = irq_base; i < irq_end; i++)
> set_irq_chip_and_handler(i, NULL, NULL);
> --
> 1.5.4.7
>
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull Request for OMAP4
On Mon, Aug 03, 2009 at 02:37:58PM +0530, Shilimkar, Santosh wrote: > Hi Russell, > > Could you please pull four patches below for the upcoming merging window. > > The patches are rebased on commit 4be3bd7849165e7efa6b0b35a23d6a3598d97465: > Linus Torvalds (1):Linux 2.6.31-rc4 > > and available in the git repository at: > > git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap4_upstream Thanks, pulled. -- 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
VDD2 setting question
Hi, I'm to trying to lower VDD2 on beagleboard to something slightly below 1V instead of the current slightly above 1V setting, but I'm having a hard time figuring out how to do that in the linux-omap (non-PM) tree. I grepped in (admittedly 2.6.29) arch/arm/mach-omap2 and it only returned hits that seem to be related to smartreflex. Now, enabling smartreflex would accomplish my goal if the beagleboards had there efuses blown, which they didn't and the debug values make some of my boards lock up :( So the questions I have are: o How do I lower VDD2 in the non-PM kernel, should I be doing it in uboot or in the kernel? o For the PM kernel, where should I go patching the VDD2 reference value? And the most important question: o Would a patch to lower the default value of VDD2 be accepted into the tree? Can it be lowered globally or should it be guarded with an machine_is_omap3beagle() clause? regards, Koen PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
On Mon, 03 Aug 2009 16:00:32 +0200 Janusz Krzysztofik wrote: > Hi, > I made more testing on my OMAP1510 and found out that I could get your > example usage working without my patch, but only if started like this: > > arecord -D hw:0,0 -f S16_LE|aplay -D hw:0,0 > > If I start the same with "-D hw:0,0" omitted from aplay, it doesn't work > any longer, waiting forever. It definitelly doesn't work if I start > capture and playback one after another, no matter which one goes first > (record while playing or play while recording). So it looks like > starting both streams simultaneously can do the job, but a short delay > breaks it. > > With my patch, it seems to work fine for me in all cases. > So it looks that McBSP-DMA for another stream cease to work if there is more than certain delay between first stream start and second one but omap_mcbsp_pollwrite or _pollread will clear the error condition. Can you debug is this due clearing the possible XSYNC_ERR, waiting for transmit/receive confirmation or playing with data registers there? > Jarkko, have you ever tried it on your OMAP2/3 with parallel playback > and capture started one after another, not simultaneously? > Yes I have. Like recording into file (arecord /dev/shm/foo) and start playing it after some time (aplay /dev/shm/foo) or playing a file and start recording into another. > If the problem appears to be OMAP1510 or AMS_DELTA specific, I can add a > check for a machine or cpu type to avoid braking unaffected machines. > I'm thinking can your platform show some existing problem not noted before... but yes, check for 1510 would be bit safer now and is also kind of revisit comment why 1510 needs special handling. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/4] TWL6030 patch series
On Mon, Aug 03, 2009 at 11:45:58AM +0530, Shilimkar, Santosh wrote: > Can you please provide your comments on the v2 version of the patches in > which Balaji has fixed the "ifdef's" They're basically OK from a regulator API point of view but the series appears to depend on the renaming patch and possibly some others. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 4/4] OMAP4: PMIC: Update TWL mfd driver to create twl6030 regulators
On Wed, Jul 29, 2009 at 10:06:13AM +0530, balaj...@ti.com wrote:
> - if (twl_has_regulator()) {
> + if (twl_has_regulator() && is_class_twl4030()) {
is_class_twl4030() feels like it should have better namespacing, though
having the part name in there means it's not actually an issue.
> @@ -306,6 +306,7 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned
> num_bytes);
> #define TWL4030_INT_PWR_EDR2 0x6
> #define TWL4030_INT_PWR_SIH_CTRL 0x7
>
> +
> /*--*/
>
> /* Power bus message definitions */
Random unrelated indentation change?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
Jarkko Nikula wrote: On Mon, 3 Aug 2009 03:32:04 +0200 Janusz Krzysztofik wrote: This patch tries to correct the problem of full duplex mode not working over a single McBSP based CPU DAI. Created against linux-2.6.31-rc5. Tested on Amstrad Delta. Do you have some specific test case how to trigger this? I haven't seen this on 2420 or 34xx (e.g. with 'arecord -d 1 -f dat |aplay') but I have no doubt that this can happen on 1510. At least this doesn't cause any harm on Beagle so I'm fine with the fix. Hi, I made more testing on my OMAP1510 and found out that I could get your example usage working without my patch, but only if started like this: arecord -D hw:0,0 -f S16_LE|aplay -D hw:0,0 If I start the same with "-D hw:0,0" omitted from aplay, it doesn't work any longer, waiting forever. It definitelly doesn't work if I start capture and playback one after another, no matter which one goes first (record while playing or play while recording). So it looks like starting both streams simultaneously can do the job, but a short delay breaks it. With my patch, it seems to work fine for me in all cases. Jarkko, have you ever tried it on your OMAP2/3 with parallel playback and capture started one after another, not simultaneously? Arun, can your snd-soc-osk9512 work on OMAP1610 in full duplex mode without any limitations? If the problem appears to be OMAP1510 or AMS_DELTA specific, I can add a check for a machine or cpu type to avoid braking unaffected machines. 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
[RFC PATCH] OMAP3:PM: Fix OPP scale logic
While switching from higher OPP to lower OPP,
current scale logic can fail by switching to lower
voltage while frequency remains at old value.
This patch adds a cleaner recovery logic and
additional freq dpll checks. This changes
program_freq_opp return type in the process
for program_opp to handle error in a consistent
manner.
Tested on:rx-51, ported to pm branch - untested linux-omap
Patch generated on linux-omap pm branch, commit:
7e7377395d6b4576341a6939bf2179f3946f2ea0
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/resource34xx.c | 52 +---
1 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/resource34xx.c
b/arch/arm/mach-omap2/resource34xx.c
index 25535a3..1ceaed8 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -240,13 +240,23 @@ static int program_opp_freq(int res, int target_level,
int current_level)
lock_scratchpad_sem();
if (res == VDD1_OPP) {
curr_opp = &curr_vdd1_opp;
- clk_set_rate(dpll1_clk, mpu_opps[target_level].rate);
- clk_set_rate(dpll2_clk, dsp_opps[target_level].rate);
+ ret = clk_set_rate(dpll1_clk, mpu_opps[target_level].rate);
+ if (unlikely(ret))
+ return ret;
+
+ ret = clk_set_rate(dpll2_clk, dsp_opps[target_level].rate);
+ if (unlikely(ret))
+ /* reset the dpll1 if failed */
+ clk_set_rate(dpll1_clk, mpu_opps[current_level].rate);
#ifndef CONFIG_CPU_FREQ
- /*Update loops_per_jiffy if processor speed is being changed*/
- loops_per_jiffy = compute_lpj(loops_per_jiffy,
- mpu_opps[current_level].rate/1000,
- mpu_opps[target_level].rate/1000);
+ else
+ /*
+* Update loops_per_jiffy if processor speed
+* is being changed
+*/
+ loops_per_jiffy = compute_lpj(loops_per_jiffy,
+ mpu_opps[current_level].rate/1000,
+ mpu_opps[target_level].rate/1000);
#endif
} else {
curr_opp = &curr_vdd2_opp;
@@ -257,7 +267,7 @@ static int program_opp_freq(int res, int target_level, int
current_level)
}
if (ret) {
unlock_scratchpad_sem();
- return current_level;
+ return ret;
}
#ifdef CONFIG_PM
omap3_save_scratchpad_contents();
@@ -265,7 +275,7 @@ static int program_opp_freq(int res, int target_level, int
current_level)
unlock_scratchpad_sem();
*curr_opp = target_level;
- return target_level;
+ return ret;
}
static int program_opp(int res, struct omap_opp *opp, int target_level,
@@ -289,13 +299,35 @@ static int program_opp(int res, struct omap_opp *opp, int
target_level,
current_level);
#ifdef CONFIG_OMAP_SMARTREFLEX
else
- sr_voltagescale_vcbypass(t_opp, c_opp,
+ ret = sr_voltagescale_vcbypass(t_opp, c_opp,
opp[target_level].vsel,
opp[current_level].vsel);
+ if (ret) {
+ int ret1 = 0;
+ /*
+* If something did not work, put me back to old state.
+* Recover the other guy if at least 1 prev iteration
+* had run
+*/
+ if (i && raise)
+ ret1 = sr_voltagescale_vcbypass(c_opp, t_opp,
+ opp[current_level].vsel,
+ opp[target_level].vsel);
+ else if (i)
+ ret1 = program_opp_freq(res, current_level,
+ target_level);
+ /*
+* If I could not reset my old state back.. system
+* is no longer in a controlled state.. bug me
+*/
+ if (unlikely(ret1))
+ BUG();
+ break;
+ }
#endif
}
- return ret;
+ return (res == PRCM_VDD1) ? curr_vdd1_opp : curr_vdd2_opp;
}
int resource_set_opp_level(int res, u32 target_level, int flags)
--
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
Re: [PATCH 00/14] OMAP PM fixes for .31-rc series
* Russell King - ARM Linux [090722 01:37]: > On Tue, Jul 21, 2009 at 03:08:26PM -0700, Kevin Hilman wrote: > > Also available here as a v2.6.31-rc3 based branch from: > > Looks fine. Ack from me too. I assume that Kevin will post a pull request for Russell so we'll get these merged. FYI, I'm back from vacation now and reading mails. Looks like there are some fixes floating around, so I'll collect those into one more omap-fixes series once I'm done reading. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Work in progress recipes for power management for overo
Hi John, A quick update... On Aug 3, 2009, at 4:42 PM, Elvis Dowson wrote: Oh, I forgot one more thing, in the linux-omap3-2.6.29.bb recipe, for the mmc there are three patches #> OMAP Patches \ file://omap/0300-mmc-clk.patch;patch=1 \ # file://omap/0301-mmc-off-mode-1.patch;patch=1 \ file://omap/0302-mmc-off-mode-2.patch;patch=1 \ Both mmc-off-mode-1 and mmc-off-mode-2 patches are similar, and I don't know which one to use. I was building mmc-off-mode-2 patch, but did test it yet and zipped it in a hurry. if you modify it as follows: #> OMAP Patches \ file://omap/0300-mmc-clk.patch;patch=1 \ file://omap/0301-mmc-off-mode-1.patch;patch=1 \ # file://omap/0302-mmc-off-mode-2.patch;patch=1 \ I just tested mmc-off-mode-2 patch, the results are identical. Both of them have the following error: mmc1: mmc_rescan - card ocr from io_op=0x, err = -110 Have you encountered this error before? A bit of background, I got those two patches from here: MMC off mode: https://review.source.android.com/#change,10666 but, I don't know what patch set 1 and patch set 2 is supposed to be. Would you happen to know ? Best regards, Elvis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] OMAP2/3: Add support for VRFB rotation engine
VRFB rotation engine is a block in OMAP2/3 that offers 12 independent
contexts that can be used for framebuffer rotation.
Each context has a backend area of real memory, where it stores the
pixels in undisclosed format. This memory is offered to users via 4
virtual memory areas, which see the same memory area in different
rotation angles (0, 90, 180 and 270 degrees).
Signed-off-by: Tomi Valkeinen
---
arch/arm/plat-omap/Kconfig |3 +
arch/arm/plat-omap/Makefile|1 +
arch/arm/plat-omap/include/mach/vrfb.h | 46 +
arch/arm/plat-omap/vrfb.c | 281
4 files changed, 331 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/vrfb.h
create mode 100644 arch/arm/plat-omap/vrfb.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ca06037..2d6ae55 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -186,6 +186,9 @@ config OMAP_SERIAL_WAKE
config OMAP2_VRAM
bool
+config OMAP2_VRFB
+ bool
+
endmenu
endif
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 0472bbe..462edf3 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -26,3 +26,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP2_VRAM) += vram.o
+obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
diff --git a/arch/arm/plat-omap/include/mach/vrfb.h
b/arch/arm/plat-omap/include/mach/vrfb.h
new file mode 100644
index 000..8790612
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vrfb.h
@@ -0,0 +1,46 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRFB_H__
+#define __OMAP_VRFB_H__
+
+#define OMAP_VRFB_LINE_LEN 2048
+
+struct vrfb {
+ u8 context;
+ void __iomem *vaddr[4];
+ unsigned long paddr[4];
+ u16 xoffset;
+ u16 yoffset;
+ u8 bytespp;
+};
+
+extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_suspend_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_resume_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp);
+extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height,
+ unsigned bytespp, bool yuv_mode);
+extern void omap_vrfb_restore_context(void);
+
+#endif /* __VRFB_H */
diff --git a/arch/arm/plat-omap/vrfb.c b/arch/arm/plat-omap/vrfb.c
new file mode 100644
index 000..240058f
--- /dev/null
+++ b/arch/arm/plat-omap/vrfb.c
@@ -0,0 +1,281 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+/*#define DEBUG*/
+
+#ifdef DEBUG
+#define DBG(format, ...) pr_debug("VRFB: " format, ## __VA_ARGS__)
+#else
+#define DBG(format, ...)
+#endif
+
+#define SMS_ROT_VIRT_BASE(context, rot) \
+ (((context >= 4) ? 0xD000 : 0x7000) \
++ (0x400 * (context)) \
++ (0x100 * (rot)))
+
+#define OMAP_VRFB_SIZE (2048 * 2048 * 4)
+
+#define VRFB_PAGE_WIDTH_EXP5 /* Assuming SDRAM pagesize= 1024 */
+#define VRFB_PAGE_HEIGHT_EXP 5 /* 1024 = 2^5 * 2^5 */
+#define VRFB_PAGE_WIDTH(1 << VRFB_PAGE_WIDTH_EXP)
+#define VRFB_PAGE_HEIGHT (1 << VRFB_PAGE_HEIGHT_EXP)
+#define SMS_IMAGEHEIGHT_OFFSET 16
+#define SMS_IMAGEWIDTH_OFFSET 0
+#define SMS_PH_OFFSET 8
+#define SMS_PW_OF
[PATCH 1/4] OMAP: OMAPFB: split omapfb.h
Split arch/arm/plat-omap/include/mach/omapfb.h into two files:
include/linux/omapfb.h - ioctls etc for userspace and some kernel
stuff for board files
drivers/video/omap/omapfb.h - for omapfb internal use
This cleans up omapfb.h and also makes it easier for the upcoming new
DSS driver to co-exist with the old driver.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap1/board-nokia770.c |2 +-
arch/arm/mach-omap2/board-n800.c |2 +-
arch/arm/mach-omap2/io.c |2 +-
arch/arm/plat-omap/fb.c |2 +-
arch/arm/plat-omap/include/mach/omapfb.h | 398 --
drivers/video/omap/blizzard.c|2 +-
drivers/video/omap/dispc.c |2 +-
drivers/video/omap/hwa742.c |2 +-
drivers/video/omap/lcd_2430sdp.c |2 +-
drivers/video/omap/lcd_ams_delta.c |2 +-
drivers/video/omap/lcd_apollon.c |2 +-
drivers/video/omap/lcd_h3.c |2 +-
drivers/video/omap/lcd_h4.c |2 +-
drivers/video/omap/lcd_inn1510.c |2 +-
drivers/video/omap/lcd_inn1610.c |2 +-
drivers/video/omap/lcd_ldp.c |2 +-
drivers/video/omap/lcd_mipid.c |3 +-
drivers/video/omap/lcd_omap2evm.c|2 +-
drivers/video/omap/lcd_omap3beagle.c |2 +-
drivers/video/omap/lcd_omap3evm.c|2 +-
drivers/video/omap/lcd_osk.c |2 +-
drivers/video/omap/lcd_overo.c |3 +-
drivers/video/omap/lcd_palmte.c |2 +-
drivers/video/omap/lcd_palmtt.c |2 +-
drivers/video/omap/lcd_palmz71.c |2 +-
drivers/video/omap/lcdc.c|3 +-
drivers/video/omap/omapfb.h | 227 +
drivers/video/omap/omapfb_main.c |2 +-
drivers/video/omap/rfbi.c|3 +-
drivers/video/omap/sossi.c |2 +-
include/linux/omapfb.h | 197 +++
31 files changed, 455 insertions(+), 427 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/mach/omapfb.h
create mode 100644 drivers/video/omap/omapfb.h
create mode 100644 include/linux/omapfb.h
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index ed2a48a..6fbde33 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -32,7 +33,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-omap2/board-n800.c b/arch/arm/mach-omap2/board-n800.c
index 23296e9..e2907ac 100644
--- a/arch/arm/mach-omap2/board-n800.c
+++ b/arch/arm/mach-omap2/board-n800.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -34,7 +35,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3a86b0f..7a54e12 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -22,13 +22,13 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index 3746222..40615a6 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -28,13 +28,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-#include
#if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE)
diff --git a/arch/arm/plat-omap/include/mach/omapfb.h
b/arch/arm/plat-omap/include/mach/omapfb.h
deleted file mode 100644
index b226bdf..000
--- a/arch/arm/plat-omap/include/mach/omapfb.h
+++ /dev/null
@@ -1,398 +0,0 @@
-/*
- * File: arch/arm/plat-omap/include/mach/omapfb.h
- *
- * Framebuffer driver for TI OMAP boards
- *
- * Copyright (C) 2004 Nokia Corporation
- * Author: Imre Deak
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __OMAPFB_H
-#define __OMAPFB_H
-
-#include
-#include
-
-/* IOCTL commands. */
-
-#define OMAP_IOW(num, dtype) _IOW('O', num, dtype)
-#define OMAP_IOR(num, dtype) _IOR('O', num, dty
[PATCH 2/4] OMAP: OMAPFB: add omapdss device
The upcoming new display subsystem driver is divided to two devices,
omapdss and omapfb, of which omapdss handles the actual hardware.
This patch adds a dummy omapdss platform device for the current omapfb
driver, which is then used to get the clocks. This will make it possible
for the current and the new display drivers to co-exist.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/clock24xx.c |8
arch/arm/mach-omap2/clock34xx.c | 10 +-
drivers/video/omap/dispc.c | 19 ---
3 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 44de027..402a3d4 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -103,10 +103,10 @@ static struct omap_clk omap24xx_clks[] = {
CLK(NULL, "mdm_ick", &mdm_ick, CK_243X),
CLK(NULL, "mdm_osc_ck", &mdm_osc_ck,CK_243X),
/* DSS domain clocks */
- CLK("omapfb", "ick", &dss_ick, CK_243X | CK_242X),
- CLK("omapfb", "dss1_fck", &dss1_fck, CK_243X | CK_242X),
- CLK("omapfb", "dss2_fck", &dss2_fck, CK_243X | CK_242X),
- CLK("omapfb", "tv_fck", &dss_54m_fck, CK_243X | CK_242X),
+ CLK("omapdss", "ick", &dss_ick, CK_243X | CK_242X),
+ CLK("omapdss", "dss1_fck", &dss1_fck, CK_243X | CK_242X),
+ CLK("omapdss", "dss2_fck", &dss2_fck, CK_243X | CK_242X),
+ CLK("omapdss", "tv_fck", &dss_54m_fck, CK_243X | CK_242X),
/* L3 domain clocks */
CLK(NULL, "core_l3_ck", &core_l3_ck,CK_243X | CK_242X),
CLK(NULL, "ssi_fck", &ssi_ssr_sst_fck, CK_243X | CK_242X),
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 045da92..dd7bba2 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -200,11 +200,11 @@ static struct omap_clk omap34xx_clks[] = {
CLK("omap_rng", "ick", &rng_ick, CK_343X),
CLK(NULL, "sha11_ick",&sha11_ick, CK_343X),
CLK(NULL, "des1_ick", &des1_ick, CK_343X),
- CLK("omapfb", "dss1_fck", &dss1_alwon_fck, CK_343X),
- CLK("omapfb", "tv_fck", &dss_tv_fck,CK_343X),
- CLK("omapfb", "video_fck",&dss_96m_fck, CK_343X),
- CLK("omapfb", "dss2_fck", &dss2_alwon_fck, CK_343X),
- CLK("omapfb", "ick", &dss_ick, CK_343X),
+ CLK("omapdss", "dss1_fck", &dss1_alwon_fck, CK_343X),
+ CLK("omapdss", "tv_fck", &dss_tv_fck,CK_343X),
+ CLK("omapdss", "video_fck",&dss_96m_fck, CK_343X),
+ CLK("omapdss", "dss2_fck", &dss2_alwon_fck, CK_343X),
+ CLK("omapdss", "ick", &dss_ick, CK_343X),
CLK(NULL, "cam_mclk", &cam_mclk, CK_343X),
CLK(NULL, "cam_ick", &cam_ick, CK_343X),
CLK(NULL, "csi2_96m_fck", &csi2_96m_fck, CK_343X),
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 06438d0..cde3d18 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -188,6 +189,11 @@ static struct {
struct omapfb_color_key color_key;
} dispc;
+static struct platform_device omapdss_device = {
+ .name = "omapdss",
+ .id = -1,
+};
+
static void enable_lcd_clocks(int enable);
static void inline dispc_write_reg(int idx, u32 val)
@@ -907,20 +913,20 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*dev)
static int get_dss_clocks(void)
{
- dispc.dss_ick = clk_get(dispc.fbdev->dev, "ick");
+ dispc.dss_ick = clk_get(&omapdss_device.dev, "ick");
if (IS_ERR(dispc.dss_ick)) {
dev_err(dispc.fbdev->dev, "can't get ick\n");
return PTR_ERR(dispc.dss_ick);
}
- dispc.dss1_fck = clk_get(dispc.fbdev->dev, "dss1_fck");
+ dispc.dss1_fck = clk_get(&omapdss_device.dev, "dss1_fck");
if (IS_ERR(dispc.dss1_fck)) {
dev_err(dispc.fbdev->dev, "can't get dss1_fck\n");
clk_put(dispc.dss_ick);
return PTR_ERR(dispc.dss1_fck);
}
- dispc.dss_54m_fck = clk_get(dispc.fbdev->dev, "tv_fck");
+ dispc.dss_54m_fck = clk_get(&omapdss_device.dev, "tv_fck");
if (IS_ERR(dispc.dss_54m_fck)) {
dev_err(dispc.fbdev->dev, "can't get tv_fck\n");
clk_put(dispc.dss_ick);
@@ -1371,6 +1377,12 @@ static int omap_dispc_init(struct omapfb_device *fbdev,
int ext_mode,
int skip_init = 0;
int i;
+ r = platform_device_register(&omapdss_device);
+ if (r) {
+ dev_err(fbdev->dev, "can't register omapdss device\n");
+ return r;
+
[PATCH 3/4] OMAP2/3: Add VRAM manager
Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:
- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations
The upcoming DSS2 uses VRAM manager.
VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/io.c |2 +
arch/arm/plat-omap/Kconfig |3 +
arch/arm/plat-omap/Makefile|1 +
arch/arm/plat-omap/include/mach/vram.h | 63 +++
arch/arm/plat-omap/sram.c |8 +
arch/arm/plat-omap/vram.c | 655
6 files changed, 732 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/vram.h
create mode 100644 arch/arm/plat-omap/vram.c
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 7a54e12..e37f736 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdev is ready */
#include "clock.h"
@@ -240,6 +241,7 @@ void __init omap2_map_common_io(void)
omap2_check_revision();
omap_sram_init();
omapfb_reserve_sdram();
+ omap_vram_reserve_sdram();
}
/*
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index efe85d0..ca06037 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -183,6 +183,9 @@ config OMAP_SERIAL_WAKE
to data on the serial RX line. This allows you to wake the
system from serial console.
+config OMAP2_VRAM
+ bool
+
endmenu
endif
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a832795..0472bbe 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -25,3 +25,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
# OMAP mailbox framework
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
+obj-$(CONFIG_OMAP2_VRAM) += vram.o
diff --git a/arch/arm/plat-omap/include/mach/vram.h
b/arch/arm/plat-omap/include/mach/vram.h
new file mode 100644
index 000..4f2c2e6
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vram.h
@@ -0,0 +1,63 @@
+/*
+ * VRAM manager for OMAP
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRAM_H__
+#define __OMAP_VRAM_H__
+
+#include
+#include
+
+#define OMAP_VRAM_MEMTYPE_SDRAM0
+#define OMAP_VRAM_MEMTYPE_SRAM 1
+#define OMAP_VRAM_MEMTYPE_MAX 1
+
+extern int omap_vram_add_region(unsigned long paddr, size_t size);
+extern int omap_vram_free(unsigned long paddr, size_t size);
+extern int omap_vram_alloc(int mtype, size_t size, unsigned long *paddr);
+extern int omap_vram_reserve(unsigned long paddr, size_t size);
+extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
+ unsigned long *largest_free_block);
+
+#ifdef CONFIG_OMAP2_VRAM
+extern void omap_vram_set_sdram_vram(u32 size, u32 start);
+extern void omap_vram_set_sram_vram(u32 size, u32 start);
+
+extern void omap_vram_reserve_sdram(void);
+extern unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+ unsigned long sram_vstart,
+ unsigned long sram_size,
+ unsigned long pstart_avail,
+ unsigned long size_avail);
+#else
+static inline void omap_vram_set_sdram_vram(u32 size, u32 start) { }
+static inline void omap_vram_set_sram_vram(u32 size, u32 start) { }
+
+static inline void omap_vram_reserve_sdram(void) { }
+static inline unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+ unsigned long sram_vstart,
+ unsigned long sram_size,
+ unsigned long pstart_avail,
+
[PATCH 0/4) OMAPFB patches
This patch set makes preparations for the new DSS2 driver. It implements VRFB support and a VRAM manager, omapfb.h is split and moved, and a dummy DSS device is created to make it possible for old DSS and new DSS2 to co-exist. VRFB and VRAM are not used by the current DSS driver. The patches are based on linux-omap, as omapfb seems to be broken in mainstream kernel. Tomi Valkeinen arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap2/board-n800.c |2 +- arch/arm/mach-omap2/clock24xx.c |8 +- arch/arm/mach-omap2/clock34xx.c | 10 +- arch/arm/mach-omap2/io.c |4 +- arch/arm/plat-omap/Kconfig |6 + arch/arm/plat-omap/Makefile |2 + arch/arm/plat-omap/fb.c |2 +- arch/arm/plat-omap/include/mach/omapfb.h | 398 -- arch/arm/plat-omap/include/mach/vram.h | 63 +++ arch/arm/plat-omap/include/mach/vrfb.h | 46 ++ arch/arm/plat-omap/sram.c|8 + arch/arm/plat-omap/vram.c| 655 ++ arch/arm/plat-omap/vrfb.c| 281 + drivers/video/omap/blizzard.c|2 +- drivers/video/omap/dispc.c | 21 +- drivers/video/omap/hwa742.c |2 +- drivers/video/omap/lcd_2430sdp.c |2 +- drivers/video/omap/lcd_ams_delta.c |2 +- drivers/video/omap/lcd_apollon.c |2 +- drivers/video/omap/lcd_h3.c |2 +- drivers/video/omap/lcd_h4.c |2 +- drivers/video/omap/lcd_inn1510.c |2 +- drivers/video/omap/lcd_inn1610.c |2 +- drivers/video/omap/lcd_ldp.c |2 +- drivers/video/omap/lcd_mipid.c |3 +- drivers/video/omap/lcd_omap2evm.c|2 +- drivers/video/omap/lcd_omap3beagle.c |2 +- drivers/video/omap/lcd_omap3evm.c|2 +- drivers/video/omap/lcd_osk.c |2 +- drivers/video/omap/lcd_overo.c |3 +- drivers/video/omap/lcd_palmte.c |2 +- drivers/video/omap/lcd_palmtt.c |2 +- drivers/video/omap/lcd_palmz71.c |2 +- drivers/video/omap/lcdc.c|3 +- drivers/video/omap/omapfb.h | 227 +++ drivers/video/omap/omapfb_main.c |2 +- drivers/video/omap/rfbi.c|3 +- drivers/video/omap/sossi.c |2 +- include/linux/omapfb.h | 197 + 40 files changed, 1543 insertions(+), 439 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Work in progress recipes for power management for overo
Hi John, Here is a link to download the omap-pm recipes for the overo that I've created so far. http://web.me.com/elvis.dowson/Download/OpenEmbedded/Entries/2009/8/3_Power_management_for_gumstix_Overo.html Let me know if you have any problems building these recipes. These recipes were original created for the corresponding android kernel builds, and I just removed the android patches from them. So, you will have to do bitbake -c menuconfig linux-omap3-2.6.29 load the defconfig file in the linux-omap3-2.6.29/overo folder, and then save it back, to remove the android specific kernel configuration settings. In the linux-omap3-2.6.29/overo/backup/defconfig folder, you will find various work in progress defconfig settings. Let me know how it goes. Oh, I forgot one more thing, in the linux-omap3-2.6.29.bb recipe, for the mmc there are three patches #> OMAP Patches \ file://omap/0300-mmc-clk.patch;patch=1 \ # file://omap/0301-mmc-off-mode-1.patch;patch=1 \ file://omap/0302-mmc-off-mode-2.patch;patch=1 \ Both mmc-off-mode-1 and mmc-off-mode-2 patches are similar, and I don't know which one to use. I was building mmc-off-mode-2 patch, but did test it yet and zipped it in a hurry. if you modify it as follows: #> OMAP Patches \ file://omap/0300-mmc-clk.patch;patch=1 \ file://omap/0301-mmc-off-mode-1.patch;patch=1 \ # file://omap/0302-mmc-off-mode-2.patch;patch=1 \ It should work fine, and all power domains will reach their target state. However, at the moment, it takes a couple of seconds for the system to come back from suspend mode. Let me know how it goes. Best regards, Elvis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC3 Overo
On Mon, 3 Aug 2009, John Sarman wrote:
> On Sun, Aug 2, 2009 at 9:20 PM, Paul Walmsley wrote:
> > From: Paul Walmsley
> > Date: Mon, 3 Aug 2009 04:18:45 +0300
> > Subject: [PATCH] OMAP3 hwmod: fix MMC3 IRQ
> >
> > The MMC3 IRQ is incorrect in mach-omap2/omap_hwmod_34xx.h, which causes
> > MMC3 init to fail.
> >
> > Signed-off-by: Paul Walmsley
> > ---
> > arch/arm/mach-omap2/omap_hwmod_34xx.h | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
> > b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> > index 29a2d60..56215bd 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
> > +++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> > @@ -470,7 +470,7 @@ static struct omap_hwmod omap34xx_mmc2_hwmod = {
> > static struct mmc_dev_attr mmc3_dev_attr;
> >
> > static u8 mmc3_mpu_irqs[] = {
> > - INT_24XX_MMC_IRQ,
> > + INT_34XX_MMC3_IRQ,
> > };
> >
> > static struct omap_hwmod_dma_info mmc3_sdma_chs[] = {
> > --
> > 1.6.3.GIT
> >
> Thanks for the patch, I will apply that and keep on testing.
I'm afraid that the patch will only be useful on a recent version of
Kevin's PM branch.
- Paul
Re: MMC3 Overo
Hi, On Aug 3, 2009, at 2:56 PM, John Sarman wrote: On Mon, Aug 3, 2009 at 6:37 AM, Elvis Dowson wrote: MMC3 connects to one of the 70 pin bottom connectors. Is this for some custom board? I am using the standard Overo Earth + palo43 combo. Just want to know if I need to apply the mmc3 patch or not. The existing mmc reader on board the overo, is it connected to mmc1 or mmc3? Best regards, Elvis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: MMC3 Overo
On Mon, Aug 3, 2009 at 6:37 AM, Elvis Dowson wrote: > Hi John, > What does MMC3 on the Overo connect to? MMC3 connects to one of the 70 pin bottom connectors. The datasheet states that MMC3 has no PBIAS circuit so you have to interface it with 1.8V logic. I used a TXS0108 from TI as a level translator. Datasheet states "The TXS0108E device is a semi-buffered auto-direction-sensing voltage translator design is optimized for translation applications (e.g. MMC Card Interfaces) that require the system to start out in a low-speed open-drain mode and then switch to a higher speed push-pull mode." So no need for transceiver control with this IC. > > I am trying to get pm working on the overo, and I have a recipe for the > overo for v.2.6.29 (which still has some issues with mmc1) and I have > v2.6.31 latest kernel update recipe for overo that has both DSS2 and PM > integrated. Have you tested the USB host with 2.6.31 recipe yet? Definitely would like the recipe for the v2.6.31. I have tested DSS2 on 2.6.30-rc8 and either I have a user error(most likely) or it wasn't working. I attempted to backport PM but as my main concern was for MMC. I stopped after realizing it wasn't absolutely necessary to get the new mmc patches to compile. > > I can share it with you if you like. > > Best regards, > > Elvis > > John Sarman -- 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: drivers that require headers in mach-omap
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley > Sent: Monday, August 03, 2009 5:04 AM > To: Pandita, Vikram > Cc: Mike Chan; Kevin Hilman; linux-omap@vger.kernel.org > Subject: RE: drivers that require headers in mach-omap > > On Fri, 31 Jul 2009, Pandita, Vikram wrote: > > > >-Original Message- > > >From: Mike Chan [mailto:m...@android.com] > > >Sent: Thursday, July 30, 2009 6:20 PM > > >To: Pandita, Vikram > > >Cc: Kevin Hilman; linux-omap@vger.kernel.org > > >Subject: Re: drivers that require headers in mach-omap > > > > > >On Thu, Jul 30, 2009 at 8:44 AM, Pandita, > Vikram wrote: > > >> > > >>>-Original Message- > > >>>From: linux-omap-ow...@vger.kernel.org > > >>>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Mike Chan > > >>>Sent: Tuesday, July 28, 2009 8:49 PM > > >>>To: Kevin Hilman; linux-omap@vger.kernel.org > > >>>Subject: drivers that require headers in mach-omap > > >>> > > >>>Omap folks, how are drivers that require access to prm and cm > > >>>registers via cm_read_mod_reg() etc... suppose to access these? > > >>> > > >>>For example if drivers/usb/host/ohci-omap.c wanted to call: > > >>>cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD, CM_IDLEST); > > >> > > >> The design was supposed to encapsulate the PRCM API's > from drivers. > > >> Driver has control over the iclk and fclk and the clock > framework > > >> would take care of any CM/PRM > > >register settings. > > >> > > >> Accessing these registers in drivers would make the > driver non-compatible for non-omap platforms. > > >> > > > > > >Are drivers such as > > > > > >drivers/usb/host/ohci-omap.c > > >drivers/usb/musb/omap2430.c > > > > > >suppose to be compatible for non-omap platforms? > > > > As you put it, no they are not. > > All PRM/CM register accesses have been restricted to > mach-omap2/plat-omap parts till now. > > The question to ask is, what functionality is missing on > enabling say the usbhost clock that clock framework is not > doing, that driver has a need to do. > > Just to follow up on this: the plan should be to remove all > PRM and CM references from those drivers. Some of those can > be replaced with clock framework calls, others may need > platform_data function pointers. To add to the list, drivers/usb/host/ehci-omap.c need a similar re-work. At the moment, it does some amount of DPLL5 programming in itself before enabling the iclk and fclk. > > > - 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 > > -- 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: MMC3 Overo
Paul,
On Sun, Aug 2, 2009 at 9:20 PM, Paul Walmsley wrote:
> Hello John,
>
> you are using the PM branch, correct?
Unfortunately I am not using the pm patch, because I am stuck at
2.6.30-rc8. This is because it is the last place I have usb host
working. I backported the necessary changes and pm wasn't an absolute
necessity, basically equivalent to not compiling in PM. I basically
used nearly every related patch after 6-6-09 - the 32 mmc patches.
>
> On Thu, 30 Jul 2009, John Sarman wrote:
>
>> On Thu, Jul 30, 2009 at 11:49 AM, John Sarman wrote:
>> > I am trying to use mmc3 on the Overo Gumstix board with no luck. I
>> > have patched the kernel with the latest changes and have yet to see a
>> > clk pulse, both before and after the patches.
>> After adding some debugging printks, I have determined the mmc3 fails
>> getting IRQ
>> mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
>> REQUEST IRQ = 83 HOST = -812068416
>> mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
>> REQUEST IRQ = 86 HOST = -812067392
>> mmci-omap-hs mmci-omap-hs.2: Failed to get debounce clock
>> REQUEST IRQ = 83 HOST = -812066368
>> mmci-omap-hs mmci-omap-hs.2: Unable to grab HSMMC IRQ
>> mmci-omap-hs mmci-omap-hs.2: Probe Failed
>> mmci-omap-hs: probe of mmci-omap-hs.2 failed with error -16
>>
>> For some reason mmc1 and mmc3 ask for the same interrupt 83 ???
>>
>> Why would this be assigned the same value?
>
> Developer error. Does this patch fix it for you?
>
>
> - Paul
>
>
> From baca68c40ec3b391cdbfc0fb20ac5092b4ab7025 Mon Sep 17 00:00:00 2001
> From: Paul Walmsley
> Date: Mon, 3 Aug 2009 04:18:45 +0300
> Subject: [PATCH] OMAP3 hwmod: fix MMC3 IRQ
>
> The MMC3 IRQ is incorrect in mach-omap2/omap_hwmod_34xx.h, which causes
> MMC3 init to fail.
>
> Signed-off-by: Paul Walmsley
> ---
> arch/arm/mach-omap2/omap_hwmod_34xx.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
> b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> index 29a2d60..56215bd 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
> +++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> @@ -470,7 +470,7 @@ static struct omap_hwmod omap34xx_mmc2_hwmod = {
> static struct mmc_dev_attr mmc3_dev_attr;
>
> static u8 mmc3_mpu_irqs[] = {
> - INT_24XX_MMC_IRQ,
> + INT_34XX_MMC3_IRQ,
> };
>
> static struct omap_hwmod_dma_info mmc3_sdma_chs[] = {
> --
> 1.6.3.GIT
>
Thanks for the patch, I will apply that and keep on testing.
John Sarman
--
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 11/20] OMAP: McBSP: Add link DMA mode selection
On Thu, Jul 30, 2009 at 03:47:25PM +0200, ext Mark Brown wrote: > On Thu, Jul 30, 2009 at 04:28:08PM +0300, Eduardo Valentin wrote: > > On Thu, Jul 30, 2009 at 03:04:42PM +0200, ext Mark Brown wrote: > > > > Is this really something that people would want to tweak at runtime > > > (except for test purposes)? > > > Yes, test purposes, bug also, the same link could be sometime used for > > low-power > > playback while sometime for low-latency processing where as accurate as > > possible DMA pointer position info is needed. > > Latency you *should* be able to infer from the application behaviour. Yes that's true. But I think using ELEMENT mode, position reports are much more accurate, which will result in more precise inferences for latencies. -- Eduardo Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
On Mon, Aug 03, 2009 at 11:29:50AM +0300, Jarkko Nikula wrote: > Janusz Krzysztofik wrote: > > + else > > + /* looks like playback already in progress, > > +* start capture by taking it out of error condition */ > > + omap_mcbsp_pollread(mcbsp_data->bus_id, &buf); > Minor note: See preferred style for multi-line comments in > Documentation/CodingStyle. I'm not 100 % sure about the braces but I > think they are also preferred if there are indented comment lines with > the single code line. Indeed; only omit the braces if the *only* thing in the block is a single statement. -- 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
Pull Request for OMAP4
Hi Russell, Could you please pull four patches below for the upcoming merging window. The patches are rebased on commit 4be3bd7849165e7efa6b0b35a23d6a3598d97465: Linus Torvalds (1):Linux 2.6.31-rc4 and available in the git repository at: git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap4_upstream Summary: Santosh Shilimkar (1): OMAP4: sDMA: Update the request lines and new registers. Syed Rafiuddin (3): ARM: OMAP4: Add McBSP support ARM: OMAP4: Add UART4 support ARM: OMAP4: Update the GPIO support arch/arm/mach-omap2/board-4430sdp.c |2 +- arch/arm/mach-omap2/mcbsp.c | 41 + arch/arm/mach-omap2/serial.c| 10 ++ arch/arm/plat-omap/gpio.c | 249 --- arch/arm/plat-omap/include/mach/dma.h | 88 +++ arch/arm/plat-omap/include/mach/mcbsp.h |8 +- arch/arm/plat-omap/mcbsp.c |2 +- 7 files changed, 346 insertions(+), 54 deletions(-) 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
Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
On Mon, Aug 03, 2009 at 10:36:38AM +0200, ext Jarkko Nikula wrote: > On Mon, 3 Aug 2009 11:11:07 +0300 > Eduardo Valentin wrote: > > > > True, but I was wondering can this same problem occur also on McBSP2 if > > > using proper size threshold? Like size near the McBSP2 audio buffer > > > (1024x32) or near the TX buffer (256x32). > > > > Yes, it can happen with mcbsp2 also if you use all places (1024+256). > > > So should the patch then take into account McBSP2 also? hmmm.. But I've seen the problem only if you use 1024+256 for mcbsp2 (0x500) or very close to that (0x4F0). I haven't seen this problem using 0x3FF, as currently is. > > -- > Jarkko > -- > 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 -- Eduardo Valentin -- 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 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
On Mon, 3 Aug 2009 11:11:07 +0300 Eduardo Valentin wrote: > > True, but I was wondering can this same problem occur also on McBSP2 if > > using proper size threshold? Like size near the McBSP2 audio buffer > > (1024x32) or near the TX buffer (256x32). > > Yes, it can happen with mcbsp2 also if you use all places (1024+256). > So should the patch then take into account McBSP2 also? -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
Hi On Mon, 3 Aug 2009 03:32:04 +0200 Janusz Krzysztofik wrote: > This patch tries to correct the problem of full duplex mode not working > over a single McBSP based CPU DAI. > > Created against linux-2.6.31-rc5. > Tested on Amstrad Delta. > Do you have some specific test case how to trigger this? I haven't seen this on 2420 or 34xx (e.g. with 'arecord -d 1 -f dat |aplay') but I have no doubt that this can happen on 1510. At least this doesn't cause any harm on Beagle so I'm fine with the fix. > @@ -191,6 +192,14 @@ static int omap_mcbsp_dai_trigger(struct > case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: > if (!mcbsp_data->active++) > omap_mcbsp_start(mcbsp_data->bus_id); > + else if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) > + /* looks like capture already in progress, > + * start playback by taking it out of error condition */ > + omap_mcbsp_pollwrite(mcbsp_data->bus_id, 0x0); > + else > + /* looks like playback already in progress, > + * start capture by taking it out of error condition */ > + omap_mcbsp_pollread(mcbsp_data->bus_id, &buf); > break; Minor note: See preferred style for multi-line comments in Documentation/CodingStyle. I'm not 100 % sure about the braces but I think they are also preferred if there are indented comment lines with the single code line. -- Jarkko -- 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 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
On Fri, Jul 31, 2009 at 07:26:11PM +0200, ext Jarkko Nikula wrote:
> On Fri, 31 Jul 2009 10:58:23 +0300
> Eduardo Valentin wrote:
>
> > On Thu, Jul 30, 2009 at 08:57:21PM +0200, ext Jarkko Nikula wrote:
> > > On Thu, 30 Jul 2009 15:49:32 +0300
> > > Eduardo Valentin wrote:
> > >
> > > > From: Peter Ujfalusi
> > > >
> > > > Do not allow applications to use the full buffer found on
> > > > McBSP1,3,4,5. Using the full buffer in threshold mode causes
> > > > the McBSP buffer to run dry, which can be observed as channels
> > > > are switching (in reality the channels are shifting).
> > > >
> > > ...
> > > > --- a/arch/arm/mach-omap2/mcbsp.c
> > > > +++ b/arch/arm/mach-omap2/mcbsp.c
> > > > @@ -129,7 +129,7 @@ static struct omap_mcbsp_platform_data
> > > > omap34xx_mcbsp_pdata[] = { .rx_irq =
> > > > INT_24XX_MCBSP1_IRQ_RX, .tx_irq =
> > > > INT_24XX_MCBSP1_IRQ_TX, .ops= &omap2_mcbsp_ops,
> > > > - .buffer_size= 0x7F,
> > > > + .buffer_size= 0x6F,
> > > > },
> > >
> > > Is it possible that also McBSP2 would require that maximum burst
> > > transmit size should be 0x10 smaller than size of internal
> > > buffer/fifo?
> >
> > That's already not at full size. There is room for 1024+256 places on
> > mcbsp2.
> >
> True, but I was wondering can this same problem occur also on McBSP2 if
> using proper size threshold? Like size near the McBSP2 audio buffer
> (1024x32) or near the TX buffer (256x32).
Yes, it can happen with mcbsp2 also if you use all places (1024+256).
>
> --
> Jarkko
--
Eduardo Valentin
--
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: warn if CONFIG_CPU_IDLE is not enabled
For MPU latency constraints to work, CONFIG_CPU_IDLE must be enabled, since CPUIdle is where the constraints are evaluated. Warn during compilation if CONFIG_CPU_IDLE is not defined. Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/resource34xx.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-omap2/resource34xx.c index 25535a3..1693e9b 100644 --- a/arch/arm/mach-omap2/resource34xx.c +++ b/arch/arm/mach-omap2/resource34xx.c @@ -28,6 +28,10 @@ #include "cm.h" #include "cm-regbits-34xx.h" +#ifndef CONFIG_CPU_IDLE +#warning MPU latency constraints require CONFIG_CPU_IDLE to function! +#endif + /** * init_latency - Initializes the mpu/core latency resource. * @resp: Latency resource to be initalized -- 1.6.3.GIT -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153
Hello Moiz,
A few remaining comments, most of these from an earlier message.
On Tue, 21 Jul 2009, Sonasath, Moiz wrote:
> When an XRDY/XDR is hit, wait for XUDF before writing data to DATA_REG.
> Otherwise some data bytes can be lost while transferring them from the
> memory to the I2C interface.
>
> Do a Busy-wait for XUDF, before writing data to DATA_REG. While waiting
> if there is NACK | AL, set the appropriate error flags, ack the pending
> interrupts and return from the ISR.
>
> Signed-off-by: Moiz Sonasath
> Signed-off-by: Vikram pandita
> ---
> drivers/i2c/busses/i2c-omap.c | 24 +++-
> 1 files changed, 23 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 05b5e4c..8deaf87 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -672,9 +672,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
> break;
> }
>
> + err = 0;
> +complete:
> omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
>
> - err = 0;
> if (stat & OMAP_I2C_STAT_NACK) {
> err |= OMAP_I2C_STAT_NACK;
> omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
> @@ -764,6 +765,27 @@ omap_i2c_isr(int this_irq, void *dev_id)
> "data to send\n");
> break;
> }
> +
> + /*
> + * OMAP3430 Errata 1.153: When an XRDY/XDR
> + * is hit, wait for XUDF before writing data
> + * to DATA_REG. Otherwise some data bytes can
> + * be lost while transferring them from the
> + * memory to the I2C interface.
> + */
Based on this description, shouldn't this patch also zero the transmit
FIFO threshold? Consider what the transmit path becomes after this patch:
1. Fill transmit FIFO
2. Leave ISR & wait for interrupt
3. Interrupt happens due to XDR/XRDY (transmit FIFO low-water-mark
reached)
4. Busy-wait until transmit FIFO & shift register completely empty
5. If more data to send, go to step #1
i2c-omap.c currently sets the transmit FIFO threshold to 1/2 of the total
FIFO size[1]. This means that, in the worst case, I2C3, the I2C ISR will
busy-wait in step 4 for the time it takes 32 bytes to be transmitted.
This is time that the MPU spends doing nothing but spinning, wasting
power. This seems unnecessary and wasteful. The time the driver spends
busy-waiting in the ISR should be reduced to the lowest possible duration.
To do this, what I suggest that you additionally do in the patch is to
reduce the transit FIFO threshold/low-water-mark, controlled by
I2C_BUF.XTRSH, to the lowest possible value. This should maximize the
time spent between steps 2 and 3 and minimize the time spent between steps
3 and 5.
Is there a reason why this can't be done?
> +
> + if (cpu_is_omap34xx()) {
Does this erratum apply to the I2C IP block on OMAP2430? It also has FIFO
transmit capability. It would be ideal if you can find out from the I2C
IP block designers. If you cannot, please consider adding a comment that
this may also apply to the I2C block on OMAP2430.
In general it is best to enable these workarounds based on the I2C IP
block's own revision register contents, not the OMAP CPU type. The goal
is to remove all these OMAP-specific "cpu_is_omap()" macros from
device drivers. For example, what if a future DaVinci part uses the same
I2C IP block?
> + while (!(stat &
> OMAP_I2C_STAT_XUDF)) {
Is there a reason why you can't just reuse the main while() loop in the
ISR, and add a state variable to handle any special casing needed in this
context? That will avoid this separate while() loop.
> + if (stat &
> (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
> +
> omap_i2c_ack_stat(dev, stat & (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
> + err |=
> OMAP_I2C_STAT_XUDF;
> + goto complete;
> + }
> + cpu_relax();
> + stat =
> omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
> + }
> + }
> +
> omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
> }
> omap_i2c_ack_stat(dev,
For those following along in the archi
