Re: [PATCH 1/2] omap: Disable TWL4030/5030 I2C1/I2C4 internal pull-ups
Hello Moiz,
On Wed, Feb 17, 2010 at 01:57:21AM +0100, ext Moiz Sonasath wrote:
> This patch disables TWL4030/5030 I2C1 adn I2C4(SR) internal pull-up, to
> use only the external HW resistor >=470 Ohm for the assured
> functionality in HS mode.
>
> While testing the I2C in High Speed mode, it was discovered that
> without a proper pull-up resistor, there is data corruption during
> multi-byte transfer. RTC(time_set) test case was used for testing.
Nice findings!
>
> >From the analysis done, it was concluded that ideally we need a
> pull-up of 1.6k Ohm(recomended) or atleast 470 Ohm or greater for
> assured performance in HS mode.
>
> Signed-off-by: Moiz Sonasath
> Signed-off-by: Allen Pais
> ---
> drivers/mfd/twl-core.c | 13 +
> include/linux/i2c/twl.h | 15 +++
> 2 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index 2a76065..35ae2ee 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -965,6 +965,7 @@ twl_probe(struct i2c_client *client, const struct
> i2c_device_id *id)
> int status;
> unsignedi;
> struct twl4030_platform_data*pdata = client->dev.platform_data;
> + u8 temp;
>
> if (!pdata) {
> dev_dbg(&client->dev, "no platform data?\n");
> @@ -1032,6 +1033,18 @@ twl_probe(struct i2c_client *client, const struct
> i2c_device_id *id)
> goto fail;
> }
>
> + /* Disable TWL4030/TWL5030 I2C Pull-up on I2C1 and I2C4(SR) interface.
> + * Program I2C_SCL_CTRL_PU(bit 0)=0, I2C_SDA_CTRL_PU (bit 2)=0,
> + * SR_I2C_SCL_CTRL_PU(bit 4)=0 and SR_I2C_SDA_CTRL_PU(bit 6)=0.
> + */
> +
> + if (twl_class_is_4030()) {
Is this run time check sufficient enough to determine if this fix must be
applied?
>From what you have described on you patch description, looks like it is
>supposed to be
only for HS mode. I don't know, maybe if you bind this to a platform / board
configuration
flag would it be better? I mean, you create a flag inside the platform data to
determine
if this fix must be applied or not. At least for me, having an external pu
resistor
seams to be very board dependent.
> + twl_i2c_read_u8(TWL4030_MODULE_INTBR, &temp, REG_GPPUPDCTR1);
> + temp &= ~(SR_I2C_SDA_CTRL_PU | SR_I2C_SCL_CTRL_PU | \
> + I2C_SDA_CTRL_PU | I2C_SCL_CTRL_PU);
> + twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
> + }
> +
> status = add_children(pdata, id->driver_data);
> fail:
> if (status < 0)
> diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
> index bf1c5be..fd95eca 100644
> --- a/include/linux/i2c/twl.h
> +++ b/include/linux/i2c/twl.h
> @@ -239,6 +239,21 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset);
>
> /*--*/
>
> +/*Interface Bit Register (INTBR) offsets
> + *(Use TWL_4030_MODULE_INTBR)
> + */
> +
> +#define REG_GPPUPDCTR1 0x0F
> +
> +/*I2C1 and I2C4(SR) SDA/SCL pull-up control bits */
> +
> +#define I2C_SCL_CTRL_PU BIT(0)
> +#define I2C_SDA_CTRL_PU BIT(2)
> +#define SR_I2C_SCL_CTRL_PU BIT(4)
> +#define SR_I2C_SDA_CTRL_PU BIT(6)
> +
> +/*--*/
> +
> /*
> * Keypad register offsets (use TWL4030_MODULE_KEYPAD)
> * ... SIH/interrupt only
> --
> 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
--
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 05/24] omap4: Add needed IRQ line into irqs.h
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Wednesday, February 17, 2010 1:03 PM > To: Shilimkar, Santosh > Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk; > sa...@linux.intel.com; > l...@slimlogic.co.uk; Cousson, Benoit > Subject: RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h > > On Wed, 17 Feb 2010, Shilimkar, Santosh wrote: > > > > -Original Message- > > > From: Paul Walmsley [mailto:p...@pwsan.com] > > > Sent: Wednesday, February 17, 2010 12:15 PM > > > To: Shilimkar, Santosh > > > Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk; > > > sa...@linux.intel.com; > > > l...@slimlogic.co.uk; Cousson, Benoit > > > Subject: RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h > > > > > > How about just submitting the auto-generated IRQ file, convert the > > > existing in-tree users, and leave the old macros there and mark them > > > deprecated with a comment? Then for the next release, submit a patch to > > > change the newly-merged users and remove the deprecated macros? > > Sounds ok if we can keep both exist for some time. Will do this. > > There shouldn't be any need to keep the old macros after the 2.6.34 merge > window. Probably the best time to remove them would be in a patch queued > for the 2.6.35 merge window. > > Any new patches that use 44xx IRQs would be required to use the > autogenerated IRQ macros after the 2.6.34 merge. > > Now would also be a good time to get the autogenerated DMA data in, for > similar reasons. Both DMA files can't co-exist since the names are aligned. I shall try DMA changes as well. 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 05/24] omap4: Add needed IRQ line into irqs.h
On Wed, 17 Feb 2010, Shilimkar, Santosh wrote: > > -Original Message- > > From: Paul Walmsley [mailto:p...@pwsan.com] > > Sent: Wednesday, February 17, 2010 12:15 PM > > To: Shilimkar, Santosh > > Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk; > > sa...@linux.intel.com; > > l...@slimlogic.co.uk; Cousson, Benoit > > Subject: RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h > > > > How about just submitting the auto-generated IRQ file, convert the > > existing in-tree users, and leave the old macros there and mark them > > deprecated with a comment? Then for the next release, submit a patch to > > change the newly-merged users and remove the deprecated macros? > Sounds ok if we can keep both exist for some time. Will do this. There shouldn't be any need to keep the old macros after the 2.6.34 merge window. Probably the best time to remove them would be in a patch queued for the 2.6.35 merge window. Any new patches that use 44xx IRQs would be required to use the autogenerated IRQ macros after the 2.6.34 merge. Now would also be a good time to get the autogenerated DMA data in, for similar reasons. - 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 05/24] omap4: Add needed IRQ line into irqs.h
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Wednesday, February 17, 2010 12:15 PM > To: Shilimkar, Santosh > Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk; > sa...@linux.intel.com; > l...@slimlogic.co.uk; Cousson, Benoit > Subject: RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h > > Hello Santosh, > > On Wed, 17 Feb 2010, Shilimkar, Santosh wrote: > > > Having said that, I think it's best time to changes this so that > > the drivers getting up streamed can use correct names directly. > > > > Also irqs-44xx.h header inclusion can be avoided in each driver if > > plat/irqs.h > > include it. > > > > I can check this if this can go in the currunt series itself. At least USB > > and MCPDM are the two drivers I know of, planned to be lined up which will > > get affected. > > > > How about doing this in the .34-rc1 so that we don't break anybody ? > > How about just submitting the auto-generated IRQ file, convert the > existing in-tree users, and leave the old macros there and mark them > deprecated with a comment? Then for the next release, submit a patch to > change the newly-merged users and remove the deprecated macros? Sounds ok if we can keep both exist for some time. Will do this. -- 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: OMAP Audio
On Tue, 16 Feb 2010 11:19:25 -0700 Gary Thomas wrote: > I need to connect the OMAP (3530) to a 24bit CODEC. So far > my attempts at getting this to go have not gone well. Then > I ran across this comment in sound/soc/omap/omap-pcm.c: > /* >* Note: Regardless of interface data formats supported by OMAP McBSP >* or EAC blocks, internal representation is always fixed 16-bit/sample >*/ > > Does this mean that this setup is just not supported? even though > the hardware can handle it? > Yep, comment is bit misleading but true until some patch will remove it. IRCC, the EAC was limited to 16-bit and also there wasn't need and HW to test other formats than S16_LE in McBSP DAI. > Thanks for any pointers or ideas on how to get this going. > I would first start adding support for the S32_LE into omap-pcm.c (DMA part). Worth to look this thread: http://mailman.alsa-project.org/pipermail/alsa-devel/2010-January/024704.html Then add support for this format to the omap-mcbsp.c (link configuration part). Next step would be to add support for the S24_LE on 4-byte boundaries. I.e. the DMA is moving 32-bit samples between the memory and McBSP but only 24-bits are transferred over the McBSP and codec. -- 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 05/24] omap4: Add needed IRQ line into irqs.h
Hello Santosh, On Wed, 17 Feb 2010, Shilimkar, Santosh wrote: > Having said that, I think it's best time to changes this so that > the drivers getting up streamed can use correct names directly. > > Also irqs-44xx.h header inclusion can be avoided in each driver if > plat/irqs.h > include it. > > I can check this if this can go in the currunt series itself. At least USB > and MCPDM are the two drivers I know of, planned to be lined up which will > get affected. > > How about doing this in the .34-rc1 so that we don't break anybody ? How about just submitting the auto-generated IRQ file, convert the existing in-tree users, and leave the old macros there and mark them deprecated with a comment? Then for the next release, submit a patch to change the newly-merged users and remove the deprecated macros? - 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
[PATCH] omap: Remove DEBUGFS dependency for mux name checking
The check for a valid mux name should be performed regardless of whether
DEBUGFS is enabled or not.
This fixes the issue currently seen with boards not booting up
if DEBUGFS is not enabled in defconfig.
Signed-off-by: Ranjith Lohithakshan
---
arch/arm/mach-omap2/mux.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 986077f..1a6ff8f 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -969,7 +969,7 @@ static void __init omap_mux_init_list(struct omap_mux
*superset)
}
#endif
-#if defined(CONFIG_OMAP_MUX) && defined(CONFIG_DEBUG_FS)
+#ifdef CONFIG_OMAP_MUX
if (!superset->muxnames || !superset->muxnames[0]) {
superset++;
continue;
--
1.6.2.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 05/24] omap4: Add needed IRQ line into irqs.h
< snip >
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> Shilimkar, Santosh
> Sent: Wednesday, February 17, 2010 11:22 AM
> To: Paul Walmsley
> Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk;
> sa...@linux.intel.com;
> l...@slimlogic.co.uk; Cousson, Benoit
> Subject: RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
> > > > > Ones omap4 hwmod is pushed on mainlie, all the
> > > > > irqs lines data would be availabe.
> > > >
> > > > Instead of this patch, why not just replace the current file with the
> > > > one
> > > > from the OMAP4 autogeneration scripts? I don't see why the IRQ macros
> > > > should depend on hwmod availability, and it would be better to have the
> > > > correct IRQ data appear in one patch, rather than having to review and
> > > > approve several smaller incremental patches over time.
> > > We plan to do this but today the autogenrated file names and one in the
> > > kernel code is different.
> >
> > File names or macro names?
> Macros ofcourse
> >
> > > Autogenrated headers are kept in alignment
> > > with TRM naming as you know.
> > > e.g
> > > --- autogenaretd
> > > #define OMAP44XX_IRQ_MCBSP2 (22 + OMAP44XX_IRQ_GIC_START)
> > >
> > > --existing kernel
> > > #define INT_44XX_MCBSP2_IRQ (22 + IRQ_GIC_START)
> > >
> > >
> > > So instead of touching every driver file and changing it only for name
> > > changes ,
> > > what we are doing
> > > 1. Created local 44xx_dma.h and 44xx_irq.h mach-omap2 directory
> > > 2. All the drivers getting converted in hwmods would use defines from
> > > above headers
> > > 3. At one point of time all the drivers would use defines from above
> > > headers and then
> > >from omap4 point of view there won't be dependency on the irqs.h and
> > > dma.h
> > >
> > > While this is ongoing, we would like the mainline kernel to have most of
> > > the
> > > drivers supported. And Hence such a patch.
> >
> > I grepped through the code base for any instances of INT_44XX:
> >
> > [p...@twilight current]$ fgrep -r INT_44XX . | fgrep -v
> > ./arch/arm/plat-omap/include/plat/irqs.h
> > ./arch/arm/mach-omap2/devices.c:.start =
> > INT_44XX_MAIL_U0_MPU,
> > ./arch/arm/mach-omap2/devices.c:irq = INT_44XX_MMC4_IRQ;
> > ./arch/arm/mach-omap2/devices.c:irq = INT_44XX_MMC5_IRQ;
> > ./arch/arm/mach-omap2/timer-mpu.c: evt->irq = INT_44XX_LOCALTIMER_IRQ;
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4a318000, .irq =
> > INT_44XX_GPTIMER1 },
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48032000, .irq =
> > INT_44XX_GPTIMER2 },
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48034000, .irq =
> > INT_44XX_GPTIMER3 },
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48036000, .irq =
> > INT_44XX_GPTIMER4 },
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x40138000, .irq =
> > INT_44XX_GPTIMER5 },
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013a000, .irq =
> > INT_44XX_GPTIMER6 },
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013a000, .irq =
> > INT_44XX_GPTIMER7 },
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013e000, .irq =
> > INT_44XX_GPTIMER8 },
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4803e000, .irq =
> > INT_44XX_GPTIMER9 },
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48086000, .irq =
> > INT_44XX_GPTIMER10 },
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48088000, .irq =
> > INT_44XX_GPTIMER11 },
> > ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4a32, .irq =
> > INT_44XX_GPTIMER12 },
> > ./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO1_BASE, NULL,
> > INT_44XX_GPIO_BANK1, IH_GPIO_BASE,
> > ./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO2_BASE, NULL,
> > INT_44XX_GPIO_BANK2, IH_GPIO_BASE +
> 32,
> > ./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO3_BASE, NULL,
> > INT_44XX_GPIO_BANK3, IH_GPIO_BASE +
> 64,
> > ./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO4_BASE, NULL,
> > INT_44XX_GPIO_BANK4, IH_GPIO_BASE +
> 96,
> > ./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO5_BASE, NULL,
> > INT_44XX_GPIO_BANK5, IH_GPIO_BASE +
> 128,
> > ./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO6_BASE, NULL,
> > INT_44XX_GPIO_BANK6, IH_GPIO_BASE +
> 160,
> > ./arch/arm/plat-omap/dma.c: irq = INT_44XX_SDMA_IRQ0;
> > [p...@twilight current]$
> >
> >
> > There are only five files to change. None of them are device
> > driver files, so they can all be merged through linux-omap. The
> > changes could easily be done in a single patch. So I see no
> > reason to not use the autogenerated IRQ file.
> >
> I think on you tree, you won't have DSS, AUDIO-ALSA, BRIDGE, USB etc.
> All these drivers needs to be updated as well
Having said that, I think it's best time to changes this so that
the drivers getting up streamed can us
RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, February 17, 2010 11:02 AM
> To: Shilimkar, Santosh
> Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk;
> sa...@linux.intel.com;
> l...@slimlogic.co.uk; Cousson, Benoit
> Subject: RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
>
> On Wed, 17 Feb 2010, Shilimkar, Santosh wrote:
>
> > > -Original Message-
> > > From: Paul Walmsley [mailto:p...@pwsan.com]
> > > Sent: Wednesday, February 17, 2010 3:39 AM
> > > To: Shilimkar, Santosh
> > > Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk;
> > > sa...@linux.intel.com;
> > > l...@slimlogic.co.uk
> > > Subject: Re: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
> > >
> > > Hello Santosh,
> > >
> > > On Tue, 16 Feb 2010, Santosh Shilimkar wrote:
> > >
> > > > This patch adds DSS, keyboard and ducati irq
> > > > entries in irqs.h
> > > >
> > > > Ones omap4 hwmod is pushed on mainlie, all the
> > > > irqs lines data would be availabe.
> > >
> > > Instead of this patch, why not just replace the current file with the one
> > > from the OMAP4 autogeneration scripts? I don't see why the IRQ macros
> > > should depend on hwmod availability, and it would be better to have the
> > > correct IRQ data appear in one patch, rather than having to review and
> > > approve several smaller incremental patches over time.
> > We plan to do this but today the autogenrated file names and one in the
> > kernel code is different.
>
> File names or macro names?
Macros ofcourse
>
> > Autogenrated headers are kept in alignment
> > with TRM naming as you know.
> > e.g
> > --- autogenaretd
> > #define OMAP44XX_IRQ_MCBSP2 (22 + OMAP44XX_IRQ_GIC_START)
> >
> > --existing kernel
> > #define INT_44XX_MCBSP2_IRQ (22 + IRQ_GIC_START)
> >
> >
> > So instead of touching every driver file and changing it only for name
> > changes ,
> > what we are doing
> > 1. Created local 44xx_dma.h and 44xx_irq.h mach-omap2 directory
> > 2. All the drivers getting converted in hwmods would use defines from above
> > headers
> > 3. At one point of time all the drivers would use defines from above
> > headers and then
> >from omap4 point of view there won't be dependency on the irqs.h and
> > dma.h
> >
> > While this is ongoing, we would like the mainline kernel to have most of the
> > drivers supported. And Hence such a patch.
>
> I grepped through the code base for any instances of INT_44XX:
>
> [p...@twilight current]$ fgrep -r INT_44XX . | fgrep -v
> ./arch/arm/plat-omap/include/plat/irqs.h
> ./arch/arm/mach-omap2/devices.c: .start =
> INT_44XX_MAIL_U0_MPU,
> ./arch/arm/mach-omap2/devices.c: irq = INT_44XX_MMC4_IRQ;
> ./arch/arm/mach-omap2/devices.c: irq = INT_44XX_MMC5_IRQ;
> ./arch/arm/mach-omap2/timer-mpu.c:evt->irq = INT_44XX_LOCALTIMER_IRQ;
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4a318000, .irq =
> INT_44XX_GPTIMER1 },
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48032000, .irq =
> INT_44XX_GPTIMER2 },
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48034000, .irq =
> INT_44XX_GPTIMER3 },
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48036000, .irq =
> INT_44XX_GPTIMER4 },
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x40138000, .irq =
> INT_44XX_GPTIMER5 },
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013a000, .irq =
> INT_44XX_GPTIMER6 },
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013a000, .irq =
> INT_44XX_GPTIMER7 },
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013e000, .irq =
> INT_44XX_GPTIMER8 },
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4803e000, .irq =
> INT_44XX_GPTIMER9 },
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48086000, .irq =
> INT_44XX_GPTIMER10 },
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48088000, .irq =
> INT_44XX_GPTIMER11 },
> ./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4a32, .irq =
> INT_44XX_GPTIMER12 },
> ./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO1_BASE, NULL,
> INT_44XX_GPIO_BANK1, IH_GPIO_BASE,
> ./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO2_BASE, NULL,
> INT_44XX_GPIO_BANK2, IH_GPIO_BASE + 32,
> ./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO3_BASE, NULL,
> INT_44XX_GPIO_BANK3, IH_GPIO_BASE + 64,
> ./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO4_BASE, NULL,
> INT_44XX_GPIO_BANK4, IH_GPIO_BASE + 96,
> ./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO5_BASE, NULL,
> INT_44XX_GPIO_BANK5, IH_GPIO_BASE + 128,
> ./arch/arm/plat-omap/gpio.c: { OMAP44XX_GPIO6_BASE, NULL,
> INT_44XX_GPIO_BANK6, IH_GPIO_BASE + 160,
> ./arch/arm/plat-omap/dma.c: irq = INT_44XX_SDMA_IRQ0;
> [p...@twilight current]$
>
>
> There are only five files to change. None of them are device
> driver files, so they can all be merged through linux-omap. The
> changes could easily be don
RE: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
On Wed, 17 Feb 2010, Shilimkar, Santosh wrote:
> > -Original Message-
> > From: Paul Walmsley [mailto:p...@pwsan.com]
> > Sent: Wednesday, February 17, 2010 3:39 AM
> > To: Shilimkar, Santosh
> > Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk;
> > sa...@linux.intel.com;
> > l...@slimlogic.co.uk
> > Subject: Re: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h
> >
> > Hello Santosh,
> >
> > On Tue, 16 Feb 2010, Santosh Shilimkar wrote:
> >
> > > This patch adds DSS, keyboard and ducati irq
> > > entries in irqs.h
> > >
> > > Ones omap4 hwmod is pushed on mainlie, all the
> > > irqs lines data would be availabe.
> >
> > Instead of this patch, why not just replace the current file with the one
> > from the OMAP4 autogeneration scripts? I don't see why the IRQ macros
> > should depend on hwmod availability, and it would be better to have the
> > correct IRQ data appear in one patch, rather than having to review and
> > approve several smaller incremental patches over time.
> We plan to do this but today the autogenrated file names and one in the
> kernel code is different.
File names or macro names?
> Autogenrated headers are kept in alignment
> with TRM naming as you know.
> e.g
> --- autogenaretd
> #define OMAP44XX_IRQ_MCBSP2 (22 + OMAP44XX_IRQ_GIC_START)
>
> --existing kernel
> #define INT_44XX_MCBSP2_IRQ (22 + IRQ_GIC_START)
>
>
> So instead of touching every driver file and changing it only for name
> changes ,
> what we are doing
> 1. Created local 44xx_dma.h and 44xx_irq.h mach-omap2 directory
> 2. All the drivers getting converted in hwmods would use defines from above
> headers
> 3. At one point of time all the drivers would use defines from above headers
> and then
>from omap4 point of view there won't be dependency on the irqs.h and dma.h
>
> While this is ongoing, we would like the mainline kernel to have most of the
> drivers supported. And Hence such a patch.
I grepped through the code base for any instances of INT_44XX:
[p...@twilight current]$ fgrep -r INT_44XX . | fgrep -v
./arch/arm/plat-omap/include/plat/irqs.h
./arch/arm/mach-omap2/devices.c:.start =
INT_44XX_MAIL_U0_MPU,
./arch/arm/mach-omap2/devices.c:irq = INT_44XX_MMC4_IRQ;
./arch/arm/mach-omap2/devices.c:irq = INT_44XX_MMC5_IRQ;
./arch/arm/mach-omap2/timer-mpu.c: evt->irq = INT_44XX_LOCALTIMER_IRQ;
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4a318000, .irq =
INT_44XX_GPTIMER1 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48032000, .irq =
INT_44XX_GPTIMER2 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48034000, .irq =
INT_44XX_GPTIMER3 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48036000, .irq =
INT_44XX_GPTIMER4 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x40138000, .irq =
INT_44XX_GPTIMER5 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013a000, .irq =
INT_44XX_GPTIMER6 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013a000, .irq =
INT_44XX_GPTIMER7 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4013e000, .irq =
INT_44XX_GPTIMER8 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4803e000, .irq =
INT_44XX_GPTIMER9 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48086000, .irq =
INT_44XX_GPTIMER10 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x48088000, .irq =
INT_44XX_GPTIMER11 },
./arch/arm/plat-omap/dmtimer.c: { .phys_base = 0x4a32, .irq =
INT_44XX_GPTIMER12 },
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO1_BASE, NULL,
INT_44XX_GPIO_BANK1, IH_GPIO_BASE,
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO2_BASE, NULL,
INT_44XX_GPIO_BANK2, IH_GPIO_BASE + 32,
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO3_BASE, NULL,
INT_44XX_GPIO_BANK3, IH_GPIO_BASE + 64,
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO4_BASE, NULL,
INT_44XX_GPIO_BANK4, IH_GPIO_BASE + 96,
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO5_BASE, NULL,
INT_44XX_GPIO_BANK5, IH_GPIO_BASE + 128,
./arch/arm/plat-omap/gpio.c:{ OMAP44XX_GPIO6_BASE, NULL,
INT_44XX_GPIO_BANK6, IH_GPIO_BASE + 160,
./arch/arm/plat-omap/dma.c: irq = INT_44XX_SDMA_IRQ0;
[p...@twilight current]$
There are only five files to change. None of them are device
driver files, so they can all be merged through linux-omap. The
changes could easily be done in a single patch. So I see no
reason to not use the autogenerated IRQ file.
> > The same reasoning should apply the DMA data also, I'd think.
> DMA file will get replaced soon with auto generated since naming
> is aligned there.
- 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 02/24] omap2/3/4: ioremap omap_globals module
< snip>
> > /**
> > diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
> > index 4f29e8c..ee9499e 100644
> > --- a/arch/arm/plat-omap/common.c
> > +++ b/arch/arm/plat-omap/common.c
> > @@ -256,11 +256,11 @@ static void __init __omap2_set_globals(struct
> > omap_globals *omap2_globals)
> > static struct omap_globals omap242x_globals = {
> > .class = OMAP242X_CLASS,
> > .tap= OMAP2_L4_IO_ADDRESS(0x48014000),
> > - .sdrc = OMAP2_L3_IO_ADDRESS(OMAP2420_SDRC_BASE),
> > - .sms= OMAP2_L3_IO_ADDRESS(OMAP2420_SMS_BASE),
> > - .ctrl = OMAP2_L4_IO_ADDRESS(OMAP2420_CTRL_BASE),
> > - .prm= OMAP2_L4_IO_ADDRESS(OMAP2420_PRM_BASE),
> > - .cm = OMAP2_L4_IO_ADDRESS(OMAP2420_CM_BASE),
> > + .sdrc = OMAP2420_SDRC_BASE,
> > + .sms= OMAP2420_SMS_BASE,
> > + .ctrl = OMAP2420_CTRL_BASE,
> > + .prm= OMAP2420_PRM_BASE,
> > + .cm = OMAP2420_CM_BASE,
> > .uart1_phys = OMAP2_UART1_BASE,
> > .uart2_phys = OMAP2_UART2_BASE,
> > .uart3_phys = OMAP2_UART3_BASE,
> > @@ -277,11 +277,11 @@ void __init omap2_set_globals_242x(void)
> > static struct omap_globals omap243x_globals = {
> > .class = OMAP243X_CLASS,
> > .tap= OMAP2_L4_IO_ADDRESS(0x4900a000),
> > - .sdrc = OMAP2_L3_IO_ADDRESS(OMAP243X_SDRC_BASE),
> > - .sms= OMAP2_L3_IO_ADDRESS(OMAP243X_SMS_BASE),
> > - .ctrl = OMAP2_L4_IO_ADDRESS(OMAP243X_CTRL_BASE),
> > - .prm= OMAP2_L4_IO_ADDRESS(OMAP2430_PRM_BASE),
> > - .cm = OMAP2_L4_IO_ADDRESS(OMAP2430_CM_BASE),
> > + .sdrc = OMAP243X_SDRC_BASE,
> > + .sms= (OMAP243X_SMS_BASE),
> > + .ctrl = (OMAP243X_CTRL_BASE),
> > + .prm= (OMAP2430_PRM_BASE),
> > + .cm = (OMAP2430_CM_BASE),
>
> Please drop the unnecessary parentheses above and elsewhere in this file.
> If the parentheses are nececessary because the macro is a composite
> expression and parentheses are missing around the expression, then the
> parentheses should be added around the macro contents itself.
>
No need of paran's. They just left out while cleaning it up.
> > .uart1_phys = OMAP2_UART1_BASE,
> > .uart2_phys = OMAP2_UART2_BASE,
> > .uart3_phys = OMAP2_UART3_BASE,
> > @@ -298,11 +298,11 @@ void __init omap2_set_globals_243x(void)
> > static struct omap_globals omap3_globals = {
> > .class = OMAP343X_CLASS,
> > .tap= OMAP2_L4_IO_ADDRESS(0x4830A000),
> > - .sdrc = OMAP2_L3_IO_ADDRESS(OMAP343X_SDRC_BASE),
> > - .sms= OMAP2_L3_IO_ADDRESS(OMAP343X_SMS_BASE),
> > - .ctrl = OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE),
> > - .prm= OMAP2_L4_IO_ADDRESS(OMAP3430_PRM_BASE),
> > - .cm = OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE),
> > + .sdrc = (OMAP343X_SDRC_BASE),
> > + .sms= (OMAP343X_SMS_BASE),
> > + .ctrl = (OMAP343X_CTRL_BASE),
> > + .prm= (OMAP3430_PRM_BASE),
> > + .cm = (OMAP3430_CM_BASE),
>
> As above.
>
> > .uart1_phys = OMAP3_UART1_BASE,
> > .uart2_phys = OMAP3_UART2_BASE,
> > .uart3_phys = OMAP3_UART3_BASE,
> > @@ -325,10 +325,10 @@ void __init omap2_set_globals_36xx(void)
> > static struct omap_globals omap4_globals = {
> > .class = OMAP443X_CLASS,
> > .tap= OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
> > - .ctrl = OMAP2_L4_IO_ADDRESS(OMAP443X_CTRL_BASE),
> > - .prm= OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
> > - .cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
> > - .cm2= OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE),
> > + .ctrl = (OMAP443X_CTRL_BASE),
> > + .prm= (OMAP4430_PRM_BASE),
> > + .cm = (OMAP4430_CM_BASE),
> > + .cm2= (OMAP4430_CM2_BASE),
>
> As above.
>
> > .uart1_phys = OMAP4_UART1_BASE,
> > .uart2_phys = OMAP4_UART2_BASE,
> > .uart3_phys = OMAP4_UART3_BASE,
> > diff --git a/arch/arm/plat-omap/include/plat/common.h
> > b/arch/arm/plat-omap/include/plat/common.h
> > index e04a58e..dc8a897 100644
> > --- a/arch/arm/plat-omap/include/plat/common.h
> > +++ b/arch/arm/plat-omap/include/plat/common.h
> > @@ -41,12 +41,12 @@ extern struct sys_timer omap_timer;
> > struct omap_globals {
> > u32 class; /* OMAP class to detect */
> > void __iomem*tap; /* Control module ID code */
> > - void __iomem*sdrc; /* SDRAM Controller */
> > - void __iomem*sms; /* SDRAM Memory Scheduler */
> > - void __iomem*ctrl; /* System Control Module */
> > - void __iomem*prm; /* Power and Reset Management */
> > - void __iomem*cm;/* Clock Management */
> > - void __iomem*cm2;
> > + unsigned long sdrc; /* SDRAM Controller */
> > + unsigned long sms;/* SDRAM Memory Scheduler */
> > + unsigned long ctrl; /* System Control Module */
> > + unsigned long prm;/* Power and Reset Management */
> > + unsigned long cm; /* Clock Management */
> > + unsigned l
RE: [PATCH 16/24] omap4: Add i2c support on omap4 platform
Thanks Paul, I am just summarizing all my responses in this email. > -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Wednesday, February 17, 2010 4:51 AM > To: Shilimkar, Santosh > Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk; > sa...@linux.intel.com; > l...@slimlogic.co.uk; Nayak, Rajendra; Syed, Rafiuddin; Ben Dooks > Subject: Re: [PATCH 16/24] omap4: Add i2c support on omap4 platform > > Hello Santosh, > > one general comment on this patch, before the specific comments. Rather > than adding more cpu_is_omap*() all over, please instead convert this code > to use flags passed in via platform_data. The I2C hwmod conversion > patches are one attempt to do that via the hwmod mechanism; you can use > that as an example of one way to do that with this driver. 1. As you suggested most of the driver clock related modifications can be avoided with dummy_nodes. Will do that. 2. Some drivers like gptimer, the clock node names chosen are different between omap4 and rest of the omaps. Since we do clk_get based on clk names, such cases, we need cpu check. Another way is to keep same clock nodes which means need to change database scripts. Which one you prefer ? 3. I shall the possibility of passing flags via board-files instead of cpu_is_() checks in drivers. This is ofcourse much cleaner approach if it's doable. -- 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 0/24] omap4 for 2.6.34
Tony, > -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Wednesday, February 17, 2010 12:33 AM > To: Shilimkar, Santosh > Cc: Ben Dooks; Samuel Ortiz; Kevin Hilman; Paul Walmsley; > l...@slimlogic.co.uk; linux- > o...@vger.kernel.org > Subject: Re: [PATCH 0/24] omap4 for 2.6.34 > > Hi, > > * Shilimkar, Santosh [100216 07:33]: > > Tony, > > Here are some patches towards upcoming 34 merge window. They are generated > > against > > linux-omap master as you suggested. > > > > I am also copying Ben, Samuel, Liam, Paul and Kevin since some of the > > changes > > are in mfd, regulator, i2c and clocks. > > Thanks. Can you please split this into several smaller sets? > > 1. Core omap changes done against linux-omap master branch >Send to linux-omap list with linux-arm-kernel Cc'd. ok > 2. Clock framework dummy_ck changes done against linux-omap master branch. >This should leave out most of the driver changes in your series. >Send to linux-omap list with linux-arm-kernel Cc'd. Will do. Some clock node names are changed and since we do clk_get based on clock node names, such drivers need to change. > 3. I2C changes against done against 2.6.33-rc8 + "Add support for 16-bit > registers" >Send to Ben and i2c list with linux-omap list Cc'd. ok > 4. MFD changes done against 2.6.33-rc8 >Send to Samuel with linux-omap list Cc'd. Sounds good. I sent this series just to ensure that we all are aligned on dependancies and also just to highlight that all of these should get merged together. Thanks for feedback. 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 24/24] omap4: multi-omap: Allow build to work
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Wednesday, February 17, 2010 12:24 AM > To: Shilimkar, Santosh > Cc: linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com; > l...@slimlogic.co.uk; > p...@pwsan.com > Subject: Re: [PATCH 24/24] omap4: multi-omap: Allow build to work > > * Santosh Shilimkar [100216 07:55]: > > The musb support is enable to omap3 platforms. For omap4 only board > > support is available and the driver still isn't supported. > > Because of this build with omap3_defconfig used for multi-omap > > doesn't work on omap4430 sdp. > > > > This patch hacks the musb probe to keep the multi-omap build > > working on omap4430 sdp > > > > Signed-off-by: Santosh Shilimkar > > --- > > drivers/usb/musb/musb_core.c |4 > > 1 files changed, 4 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c > > index bcce8e8..13b1c4a 100644 > > --- a/drivers/usb/musb/musb_core.c > > +++ b/drivers/usb/musb/musb_core.c > > @@ -2124,6 +2124,10 @@ static int __init musb_probe(struct platform_device > > *pdev) > > struct resource *iomem; > > void __iomem*base; > > > > + /* FIXME: multi-omap build to work on omap4 */ > > + if (cpu_is_omap44xx()) > > + return 0; > > + > > iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > if (!iomem || irq == 0) > > return -ENODEV; > > Should the comment here be "FIXME: allow multi-omap to boot until > musb is updated for omap4" instead? yeah -- 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 16/24] omap4: Add i2c support on omap4 platform
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Wednesday, February 17, 2010 12:21 AM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com;
> l...@slimlogic.co.uk;
> p...@pwsan.com; Syed, Rafiuddin; Ben Dooks
> Subject: Re: [PATCH 16/24] omap4: Add i2c support on omap4 platform
>
> * Santosh Shilimkar [100216 07:55]:
> > This patch is rebased version of earlier post to add I2C
> > driver support to OMAP4 platform. On OMAP4, all
> > I2C register address offsets are changed from OMAP1/2/3 I2C.
> > In order to not have #ifdef's at various places in code,
> > as well as to support multi-OMAP build, an array is created
> > to hold the register addresses with it's offset.
> >
> > This patch was submitted, reviewed and acked on mailing list
> > already. For more details refer below link
> > http://www.mail-archive.com/linux-...@vger.kernel.org/msg02281.html
> >
> > This version updated on top of 16 bit support added as part of
> > the commit "8bb209278e555a626f9637e844fe4c1b90e849f6"
> >
> > Signed-off-by: Syed Rafiuddin
> > Signed-off-by: Santosh Shilimkar
> > Acked-by: Kevin Hilman
> > CC: Tony Lindgren
> > CC: Ben Dooks
> > ---
> > arch/arm/plat-omap/i2c.c | 17 -
> > drivers/i2c/busses/i2c-omap.c | 148
> > -
> > 2 files changed, 131 insertions(+), 34 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
> > index 96d2781..f18d757 100644
> > --- a/arch/arm/plat-omap/i2c.c
> > +++ b/arch/arm/plat-omap/i2c.c
> > @@ -53,9 +53,15 @@ static struct resource i2c_resources[][2] = {
> > #ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> > { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE2, INT_24XX_I2C2_IRQ) },
> > #endif
> > +#ifdefined(CONFIG_ARCH_OMAP4)
> > + { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE2, INT_44XX_I2C2_IRQ) },
> > +#endif
> > #ifdefined(CONFIG_ARCH_OMAP3)
> > { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE3, INT_34XX_I2C3_IRQ) },
> > #endif
> > +#ifdefined(CONFIG_ARCH_OMAP4)
> > + { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE3, INT_44XX_I2C3_IRQ) },
> > +#endif
> > };
>
> This is OK, but..
>
> > #define I2C_DEV_BUILDER(bus_id, res, data) \
> > @@ -72,10 +78,11 @@ static struct resource i2c_resources[][2] = {
> > static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
> > static struct platform_device omap_i2c_devices[] = {
> > I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_rate[0]),
> > -#ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> > +#ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
> > + defined(CONFIG_ARCH_OMAP4)
> > I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
> > #endif
> > -#ifdefined(CONFIG_ARCH_OMAP3)
> > +#ifdefined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> > I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
> > #endif
> > };
>
> .. the ifdefs above can be simplified to ifdef CONFIG_ARCH_OMAP2PLUS.
> That is, with the patches already queued into omap for-next.
YEP
>
> > @@ -370,7 +434,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> > internal_clk = 9600;
> > else
> > internal_clk = 4000;
> > - fclk_rate = clk_get_rate(dev->fclk) / 1000;
> > + /* FIXME: Remove this once clock framework is available*/
> > + if (dev->rev >= OMAP_I2C_REV_ON_4430)
> > + fclk_rate = 96000;
> > + else
> > + fclk_rate = clk_get_rate(dev->fclk) / 1000;
> >
> > /* Compute prescaler divisor */
> > psc = fclk_rate / internal_clk;
>
> Sounds like this part should no longer be needed?
>
Yes. I missed this
> > *dev->buf++ = w;
> > dev->buf_len--;
> > - /* Data reg from 2430 is 8 bit wide */
> > + /* Data reg in 2430, omap3 and
> > +* omap4 is 8 bit wide
> > +*/
> > if (!cpu_is_omap2430() &&
> > - !cpu_is_omap34xx()) {
> > + !cpu_is_omap34xx() &&
> > + !cpu_is_omap44xx()) {
> > if (dev->buf_len) {
> > *dev->buf++ = w >> 8;
> > dev->buf_len--;
>
> How about change this to if (cpu_class_is_omap1() || cpu_is_omap2420())?
> That way it does not need to be patched for new omaps.
>
> > @@ -786,9 +857,12 @@ complete:
> > if (dev->buf_len) {
> > w = *dev->buf++;
> >
RE: [PATCH 13/24] omap4: clocks: Remove clock hacks from timer-gp.c
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Wednesday, February 17, 2010 12:12 AM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com;
> l...@slimlogic.co.uk;
> p...@pwsan.com
> Subject: Re: [PATCH 13/24] omap4: clocks: Remove clock hacks from timer-gp.c
>
> * Santosh Shilimkar [100216 07:55]:
> > Now the omap4 clock framework is mainline and clk_get_rate()
> > is functional. Hence reomve the hardcoded clock hacks.
>
> Should we send this as a fix for 2.6.33, or does this depend
> on other patches not yet in 2.6.33?
This needs the gptimer clocks updates in dmtimer.
> Regards,
>
> Tony
>
> > This patch also fixes
> > Division by zero in kernel.
> > Backtrace:
> > [] (dump_backtrace+0x0/0x110) from []
> > (dump_stack+0x18/0x1c)
> > r7:6093 r6:c0641050 r5:c0223e78 r4:c02126b4
> > [] (dump_stack+0x0/0x1c) from [] (__div0+0x18/0x20)
> > [] (__div0+0x0/0x20) from [] (Ldiv0+0x8/0x10)
> > [] (omap_dm_timer_stop+0x0/0xb0) from []
> > (omap2_gp_timer_set_mode+0x1c/0x68)
> > r5:c0223e78 r4:
> > [] (omap2_gp_timer_set_mode+0x0/0x68) from []
> > (clockevents_set_mode+0x30/0x64)
> > r5:c020cae0 r4:
> > [] (clockevents_set_mode+0x0/0x64) from []
> (clockevents_exchange_device+0x30/0x9c)
> > r5:c020cae0 r4:c02146e0
> > [] (clockevents_exchange_device+0x0/0x9c) from []
> > (tick_notify+0x17c/0x404)
> > r7: r6:c0641050 r5: r4:c020cae0
> > [] (tick_notify+0x0/0x404) from []
> > (notifier_call_chain+0x34/0x78)
> > [] (notifier_call_chain+0x0/0x78) from []
> > (__raw_notifier_call_chain+0x1c/0x24)
> > [] (__raw_notifier_call_chain+0x0/0x24) from []
> (raw_notifier_call_chain+0x20/0x28)
> > [] (raw_notifier_call_chain+0x0/0x28) from []
> > (clockevents_do_notify+0x1c/0x24)
> > [] (clockevents_do_notify+0x0/0x24) from []
> (clockevents_register_device+0x98/0xd0)
> > [] (clockevents_register_device+0x0/0xd0) from []
> (percpu_timer_setup+0x80/0x9c)
> > r7: r6:0002 r5:0002 r4:0003
> > [] (percpu_timer_setup+0x0/0x9c) from []
> > (smp_prepare_cpus+0xb0/0xe8)
> > [] (smp_prepare_cpus+0x0/0xe8) from []
> > (kernel_init+0x5c/0x1fc)
> > r7: r6: r5: r4:c001b8a4
> > [] (kernel_init+0x0/0x1fc) from [] (do_exit+0x0/0x604)
> > r7: r6: r5: r4:
> >
> > Signed-off-by: Santosh Shilimkar
> > ---
> > arch/arm/mach-omap2/timer-gp.c |5 -
> > 1 files changed, 0 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
> > index cd04dea..74fbed8 100644
> > --- a/arch/arm/mach-omap2/timer-gp.c
> > +++ b/arch/arm/mach-omap2/timer-gp.c
> > @@ -85,8 +85,6 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
> > mode,
> > case CLOCK_EVT_MODE_PERIODIC:
> > period = clk_get_rate(omap_dm_timer_get_fclk(gptimer)) / HZ;
> > period -= 1;
> > - if (cpu_is_omap44xx())
> > - period = 0xff; /* FIXME: */
> > omap_dm_timer_set_load_start(gptimer, 1, 0x - period);
> > break;
> > case CLOCK_EVT_MODE_ONESHOT:
> > @@ -150,9 +148,6 @@ static void __init omap2_gp_clockevent_init(void)
> > "timer-gp: omap_dm_timer_set_source() failed\n");
> >
> > tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer));
> > - if (cpu_is_omap44xx())
> > - /* Assuming 32kHz clk is driving GPT1 */
> > - tick_rate = 32768; /* FIXME: */
> >
> > pr_info("OMAP clockevent source: GPTIMER%d at %u Hz\n",
> > gptimer_id, tick_rate);
> > --
> > 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 05/24] omap4: Add needed IRQ line into irqs.h
Paul, > -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Wednesday, February 17, 2010 3:39 AM > To: Shilimkar, Santosh > Cc: t...@atomide.com; linux-omap@vger.kernel.org; b...@fluff.org.uk; > sa...@linux.intel.com; > l...@slimlogic.co.uk > Subject: Re: [PATCH 05/24] omap4: Add needed IRQ line into irqs.h > > Hello Santosh, > > On Tue, 16 Feb 2010, Santosh Shilimkar wrote: > > > This patch adds DSS, keyboard and ducati irq > > entries in irqs.h > > > > Ones omap4 hwmod is pushed on mainlie, all the > > irqs lines data would be availabe. > > Instead of this patch, why not just replace the current file with the one > from the OMAP4 autogeneration scripts? I don't see why the IRQ macros > should depend on hwmod availability, and it would be better to have the > correct IRQ data appear in one patch, rather than having to review and > approve several smaller incremental patches over time. We plan to do this but today the autogenrated file names and one in the kernel code is different. Autogenrated headers are kept in alignment with TRM naming as you know. e.g --- autogenaretd #define OMAP44XX_IRQ_MCBSP2 (22 + OMAP44XX_IRQ_GIC_START) --existing kernel #define INT_44XX_MCBSP2_IRQ (22 + IRQ_GIC_START) So instead of touching every driver file and changing it only for name changes , what we are doing 1. Created local 44xx_dma.h and 44xx_irq.h mach-omap2 directory 2. All the drivers getting converted in hwmods would use defines from above headers 3. At one point of time all the drivers would use defines from above headers and then from omap4 point of view there won't be dependency on the irqs.h and dma.h While this is ongoing, we would like the mainline kernel to have most of the drivers supported. And Hence such a patch. > The same reasoning should apply the DMA data also, I'd think. DMA file will get replaced soon with auto generated since naming is aligned there. 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 2/2] DSPBRIDGE: New reserved memory accounting framework
Hi,
>-Original Message-
>From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
>Sent: Tuesday, February 16, 2010 12:43 PM
>To: Ameya Palande
>Cc: linux-omap@vger.kernel.org; felipe.contre...@nokia.com; Menon,
>Nishanth; Chitriki Rudramuni, Deepak; Ramirez Luna, Omar; Guzman Lugo,
>Fernando
>Subject: Re: [PATCH 2/2] DSPBRIDGE: New reserved memory accounting
>framework
>
>On Tue, Feb 16, 2010 at 3:20 PM, Ameya Palande
>wrote:
>> DSP_RSV_OBJECT is introduced to track reserved memory accounting
>information.
>> This will allow us to do proper cleanup for memory reserved using
>> PROC_ReserveMemory().
>>
>> Signed-off-by: Ameya Palande
>> ---
>> arch/arm/plat-omap/include/dspbridge/drv.h | 13 ++
>> arch/arm/plat-omap/include/dspbridge/proc.h | 5 +-
>> drivers/dsp/bridge/pmgr/dmm.c | 3 +-
>> drivers/dsp/bridge/pmgr/wcd.c | 7 ++-
>> drivers/dsp/bridge/rmgr/drv.c | 27 +---
>> drivers/dsp/bridge/rmgr/drv_interface.c | 7 ++-
>> drivers/dsp/bridge/rmgr/node.c | 5 +-
>> drivers/dsp/bridge/rmgr/proc.c | 58
>+-
>> 8 files changed, 97 insertions(+), 28 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h b/arch/arm/plat-
>omap/include/dspbridge/drv.h
>> index 3069e74..6e8187d 100644
>> --- a/arch/arm/plat-omap/include/dspbridge/drv.h
>> +++ b/arch/arm/plat-omap/include/dspbridge/drv.h
>> @@ -101,6 +101,15 @@ struct DMM_MAP_OBJECT {
>> struct DMM_MAP_OBJECT *next;
>> } ;
>>
>> +/*
>> + * New structure (member of process context) used for accounting of DMM
>> + * reserved memory information
>> + */
>> +struct DMM_RSV_OBJECT {
>> + struct list_head link;
>> + u32 dsp_reserved_addr;
>> +};
>> +
>> /* New structure (member of process context) abstracts DMM resource info
>*/
>> struct DSPHEAP_RES_OBJECT {
>> s32 heapAllocated; /* DMM status */
>> @@ -141,6 +150,10 @@ struct PROCESS_CONTEXT{
>> /* DMM mapped memory resources */
>> struct DMM_MAP_OBJECT *dmm_map_list;
>>
>> + /* DMM reserved memory resources */
>> + struct list_head dmm_rsv_list;
>> + spinlock_t dmm_rsv_list_lock;
>> +
>
>Why rsv requires a spinlock, but not map?
>
>I guess it would be needed if somehow PROC_UnReserveMemory() was
>called by user-space at the same time than bridge_close, but is that
>really possible? If it is, then the same danger is present with
>PROC_UnMap() unless I'm missing something.
No, that's not possible. However protection is still needed for PROC_
ReserveMemory/UnReserveMemory and also for PROC_Map/UnMap.
Regards,
Fernando.
>
>> /* DSP Heap resources */
>> struct DSPHEAP_RES_OBJECT *pDSPHEAPList;
>>
>> diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h b/arch/arm/plat-
>omap/include/dspbridge/proc.h
>> index 8dbdaac..558c053 100644
>> --- a/arch/arm/plat-omap/include/dspbridge/proc.h
>> +++ b/arch/arm/plat-omap/include/dspbridge/proc.h
>> @@ -560,7 +560,7 @@
>> * Details:
>> */
>> extern DSP_STATUS PROC_ReserveMemory(DSP_HPROCESSOR hProcessor,
>> - u32 ulSize, void
>**ppRsvAddr);
>> + u32 ulSize, void **ppRsvAddr, struct PROCESS_CONTEXT
>*pr_ctxt);
>>
>> /*
>> * PROC_UnMap
>> @@ -604,6 +604,7 @@
>> * Details:
>> */
>> extern DSP_STATUS PROC_UnReserveMemory(DSP_HPROCESSOR hProcessor,
>> - void *pRsvAddr);
>> + void *pRsvAddr, struct PROCESS_CONTEXT *pr_ctxt,
>> + int cleanup);
>>
>> #endif /* PROC_ */
>> diff --git a/drivers/dsp/bridge/pmgr/dmm.c
>b/drivers/dsp/bridge/pmgr/dmm.c
>> index d5a7275..72aee60 100644
>> --- a/drivers/dsp/bridge/pmgr/dmm.c
>> +++ b/drivers/dsp/bridge/pmgr/dmm.c
>> @@ -386,9 +386,10 @@ DSP_STATUS DMM_ReserveMemory(struct DMM_OBJECT
>*hDmmMgr, u32 size,
>> node->MappedSize = 0;
>> /* Return the chunk's starting address */
>> *pRsvAddr = rsvAddr;
>> - } else
>> + } else {
>> /*dSP chunk of given size is not available */
>> status = DSP_EMEMORY;
>> + }
>>
>> SYNC_LeaveCS(pDmmObj->hDmmLock);
>> GT_3trace(DMM_debugMask, GT_4CLASS,
>> diff --git a/drivers/dsp/bridge/pmgr/wcd.c
>b/drivers/dsp/bridge/pmgr/wcd.c
>> index beea23b..747d069 100644
>> --- a/drivers/dsp/bridge/pmgr/wcd.c
>> +++ b/drivers/dsp/bridge/pmgr/wcd.c
>> @@ -1054,12 +1054,13 @@ u32 PROCWRAP_ReserveMemory(union Trapped_Args
>*args, void *pr_ctxt)
>>
>> GT_0trace(WCD_debugMask, GT_ENTER, "PROCWRAP_ReserveMemory:
>entered\n");
>> status = PROC_ReserveMemory(args->ARGS_PROC_RSVMEM.hProcessor,
>> - args->ARGS_PROC_RSVMEM.ulSize,
>&pRsvAddr);
>> + args->ARGS_PROC_RSVMEM.ulSize,
>&pRsv
RE: [PATCH 2/2] DSPBRIDGE: New reserved memory accounting framework
Hi,
>-Original Message-
>From: Ameya Palande [mailto:ameya.pala...@nokia.com]
>Sent: Tuesday, February 16, 2010 7:20 AM
>To: linux-omap@vger.kernel.org
>Cc: felipe.contre...@nokia.com; Menon, Nishanth; Chitriki Rudramuni,
>Deepak; Ramirez Luna, Omar; Guzman Lugo, Fernando
>Subject: [PATCH 2/2] DSPBRIDGE: New reserved memory accounting framework
>
>DSP_RSV_OBJECT is introduced to track reserved memory accounting
>information.
>This will allow us to do proper cleanup for memory reserved using
>PROC_ReserveMemory().
>
>Signed-off-by: Ameya Palande
>---
> arch/arm/plat-omap/include/dspbridge/drv.h | 13 ++
> arch/arm/plat-omap/include/dspbridge/proc.h |5 +-
> drivers/dsp/bridge/pmgr/dmm.c |3 +-
> drivers/dsp/bridge/pmgr/wcd.c |7 ++-
> drivers/dsp/bridge/rmgr/drv.c | 27 +---
> drivers/dsp/bridge/rmgr/drv_interface.c |7 ++-
> drivers/dsp/bridge/rmgr/node.c |5 +-
> drivers/dsp/bridge/rmgr/proc.c | 58 +--
>---
> 8 files changed, 97 insertions(+), 28 deletions(-)
>
>diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h b/arch/arm/plat-
>omap/include/dspbridge/drv.h
>index 3069e74..6e8187d 100644
>--- a/arch/arm/plat-omap/include/dspbridge/drv.h
>+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
>@@ -101,6 +101,15 @@ struct DMM_MAP_OBJECT {
> struct DMM_MAP_OBJECT *next;
> } ;
>
>+/*
>+ * New structure (member of process context) used for accounting of DMM
>+ * reserved memory information
>+ */
>+struct DMM_RSV_OBJECT {
>+ struct list_head link;
>+ u32 dsp_reserved_addr;
>+};
>+
> /* New structure (member of process context) abstracts DMM resource info
>*/
> struct DSPHEAP_RES_OBJECT {
> s32heapAllocated; /* DMM status */
>@@ -141,6 +150,10 @@ struct PROCESS_CONTEXT{
> /* DMM mapped memory resources */
> struct DMM_MAP_OBJECT *dmm_map_list;
>
>+ /* DMM reserved memory resources */
>+ struct list_head dmm_rsv_list;
>+ spinlock_t dmm_rsv_list_lock;
>+
> /* DSP Heap resources */
> struct DSPHEAP_RES_OBJECT *pDSPHEAPList;
>
>diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h b/arch/arm/plat-
>omap/include/dspbridge/proc.h
>index 8dbdaac..558c053 100644
>--- a/arch/arm/plat-omap/include/dspbridge/proc.h
>+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
>@@ -560,7 +560,7 @@
> * Details:
> */
> extern DSP_STATUS PROC_ReserveMemory(DSP_HPROCESSOR hProcessor,
>- u32 ulSize, void **ppRsvAddr);
>+ u32 ulSize, void **ppRsvAddr, struct PROCESS_CONTEXT *pr_ctxt);
>
> /*
> * PROC_UnMap
>@@ -604,6 +604,7 @@
> * Details:
> */
> extern DSP_STATUS PROC_UnReserveMemory(DSP_HPROCESSOR hProcessor,
>- void *pRsvAddr);
>+ void *pRsvAddr, struct PROCESS_CONTEXT *pr_ctxt,
>+ int cleanup);
>
> #endif/* PROC_ */
>diff --git a/drivers/dsp/bridge/pmgr/dmm.c b/drivers/dsp/bridge/pmgr/dmm.c
>index d5a7275..72aee60 100644
>--- a/drivers/dsp/bridge/pmgr/dmm.c
>+++ b/drivers/dsp/bridge/pmgr/dmm.c
>@@ -386,9 +386,10 @@ DSP_STATUS DMM_ReserveMemory(struct DMM_OBJECT
>*hDmmMgr, u32 size,
> node->MappedSize = 0;
> /* Return the chunk's starting address */
> *pRsvAddr = rsvAddr;
>- } else
>+ } else {
> /*dSP chunk of given size is not available */
> status = DSP_EMEMORY;
>+ }
>
> SYNC_LeaveCS(pDmmObj->hDmmLock);
> GT_3trace(DMM_debugMask, GT_4CLASS,
>diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
>index beea23b..747d069 100644
>--- a/drivers/dsp/bridge/pmgr/wcd.c
>+++ b/drivers/dsp/bridge/pmgr/wcd.c
>@@ -1054,12 +1054,13 @@ u32 PROCWRAP_ReserveMemory(union Trapped_Args
>*args, void *pr_ctxt)
>
> GT_0trace(WCD_debugMask, GT_ENTER, "PROCWRAP_ReserveMemory:
>entered\n");
> status = PROC_ReserveMemory(args->ARGS_PROC_RSVMEM.hProcessor,
>- args->ARGS_PROC_RSVMEM.ulSize, &pRsvAddr);
>+ args->ARGS_PROC_RSVMEM.ulSize, &pRsvAddr,
>+ pr_ctxt);
> if (DSP_SUCCEEDED(status)) {
> if (put_user(pRsvAddr, args->ARGS_PROC_RSVMEM.ppRsvAddr)) {
> status = DSP_EINVALIDARG;
> PROC_UnReserveMemory(args->ARGS_PROC_RSVMEM.hProcessor,
>- pRsvAddr);
>+ pRsvAddr, pr_ctxt, 1);
> }
> }
> return status;
>@@ -1100,7 +1101,7 @@ u32 PROCWRAP_UnReserveMemory(union Trapped_Args
>*args, void *pr_ctxt)
> GT_0trace(WCD_debugMask, GT_ENTER,
>"PROCWRAP_UnReserveMemory: entered\n");
> status = PROC_UnReserveMemory(args->ARGS_PROC_UNRSVMEM.hProcessor,
>-
Re: [PATCH/RFC 1/2] OMAP: omap_device: add omap_device_has_lost_context()
Hi Kevin,
a few questions:
On Wed, 3 Feb 2010, Kevin Hilman wrote:
> Add new function omap_device_has_lost_context() as a simple check
> to be used after omap_device_enable() to determine if device has
> lost context (and thus needs context restore.)
>
> Motivation: Currently, each driver needs to read the context-loss
> count before suspend, and again upon resume to determine if
> device context needs to be restored. Rather than duplicating
> this process across all drivers, move it into omap_device. After
> omap_device_enable(), omap_device_has_lost_context() can be called
> to determine if context was lost.
>
> This API is not intended for direct use by drivers. Rather, the
> OMAP runtime PM core will use this to determine whether or not
> to call the drivers runtime_resume hook which can then be used to
> restore context.
>
> The goal is to only call drivers "restore" hook when necessary.
>
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/plat-omap/include/plat/omap_device.h |3 ++
> arch/arm/plat-omap/omap_device.c | 35
> +
> 2 files changed, 38 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
> b/arch/arm/plat-omap/include/plat/omap_device.h
> index 76d4917..ff98eb4 100644
> --- a/arch/arm/plat-omap/include/plat/omap_device.h
> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
> @@ -71,6 +71,8 @@ struct omap_device {
> s8 pm_lat_level;
> u8 hwmods_cnt;
> u8 _state;
> + u32 activate_loss_cnt;
> + u32 deactivate_loss_cnt;
Would it be sufficient to just note the context loss count on a disable
and then compare it against the powerdomain's loss count during activate,
and if different, set a flag in _state ? That way only one loss count
variable would be needed.
> };
>
> /* Device driver interface (call via platform_data fn ptrs) */
> @@ -78,6 +80,7 @@ struct omap_device {
> int omap_device_enable(struct platform_device *pdev);
> int omap_device_idle(struct platform_device *pdev);
> int omap_device_shutdown(struct platform_device *pdev);
> +bool omap_device_has_lost_context(struct platform_device *pdev);
>
> /* Core code interface */
>
> diff --git a/arch/arm/plat-omap/omap_device.c
> b/arch/arm/plat-omap/omap_device.c
> index d8c75c8..aaa009d 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -84,6 +84,7 @@
>
> #include
> #include
> +#include
>
> /* These parameters are passed to _omap_device_{de,}activate() */
> #define USE_WAKEUP_LAT 0
> @@ -119,6 +120,7 @@
> static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
> {
> struct timespec a, b, c;
> + struct powerdomain *pwrdm;
>
> pr_debug("omap_device: %s: activating\n", od->pdev.name);
>
> @@ -168,6 +170,10 @@ static int _omap_device_activate(struct omap_device *od,
> u8 ignore_lat)
> od->dev_wakeup_lat -= odpl->activate_lat;
> }
>
> + pwrdm = omap_device_get_pwrdm(od);
> + if (pwrdm)
> + od->activate_loss_cnt = pwrdm->state_counter[PWRDM_POWER_OFF];
This probably will also depend on the powerdomain's logic_retst,
mem_retst, mem_onst bits, since context can be lost even when the
powerdomain is in RET or ON state.
> +
> return 0;
> }
>
> @@ -188,6 +194,7 @@ static int _omap_device_activate(struct omap_device *od,
> u8 ignore_lat)
> static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
> {
> struct timespec a, b, c;
> + struct powerdomain *pwrdm;
>
> pr_debug("omap_device: %s: deactivating\n", od->pdev.name);
>
> @@ -239,6 +246,10 @@ static int _omap_device_deactivate(struct omap_device
> *od, u8 ignore_lat)
> od->pm_lat_level++;
> }
>
> + pwrdm = omap_device_get_pwrdm(od);
> + if (pwrdm)
> + od->deactivate_loss_cnt = pwrdm->state_counter[PWRDM_POWER_OFF];
Same comment as above.
> +
> return 0;
> }
>
> @@ -560,6 +571,30 @@ int omap_device_shutdown(struct platform_device *pdev)
> }
>
> /**
> + * omap_device_has_lost_context() - check if omap_device has lost context
> + * @od: struct omap_device *
> + *
> + * When an omap_device has been deactivated via omap_device_idle() or
> + * omap_device_shutdown() and then (re)activated using omap_device_enable()
> + * This function should be used to determine if the omap_device has
> + * lost context (due to an off-mode transistion)
> + */
> +bool omap_device_has_lost_context(struct platform_device *pdev)
> +{
> + struct omap_device *od;
> +
> + od = _find_by_pdev(pdev);
> +
> + if (od->_state != OMAP_DEVICE_STATE_ENABLED) {
> + WARN(1, "omap_device: %s.%d: has_lost_context() called "
> + "from invalid state\n", od->pdev.na
[no subject]
This patch disables the newly introduced internal pull-up feature in
OMAP3630, to use only the external HW resitor >= 470 Ohm for the
assured functionality in HS mode.
While testing the I2C in High Speed mode, it was discovered that
without a proper pull-up resitor, there is data corruption during
multi-byte transfers. RTC(time_set) test case was used for testing.
>From the analysis done, it was concluded that ideally we need a pull-up
of 1.6 K Ohm (recomended) or atleast 470 Ohm or greater for assured
performance in HS mode.
Signed-off-by: Moiz Sonasath
Signed-off-by: Allen Pais
Signed-off-by: Vikram Pandita
---
arch/arm/mach-omap2/i2c.c | 24
arch/arm/plat-omap/include/plat/control.h | 14 ++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c
index 789ca8c..2e6eb28 100644
--- a/arch/arm/mach-omap2/i2c.c
+++ b/arch/arm/mach-omap2/i2c.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "mux.h"
@@ -52,5 +53,28 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
omap_mux_init_signal(mux_name, OMAP_PIN_INPUT);
}
+ /* Disable OMAP 3630 internal pull-ups for all I2Ci */
+ if (cpu_is_omap3630() && !(omap_ctrl_readl(OMAP343X_CONTROL_PROG_IO1) &
OMAP3630_PRG_I2C1_PULLUPRESX)) {
+
+ u32 prog_io;
+
+ prog_io = omap_ctrl_readl(OMAP343X_CONTROL_PROG_IO1);
+ /* Program (bit 19)=1 to disable internal pull-up on I2C1 */
+ prog_io |= OMAP3630_PRG_I2C1_PULLUPRESX;
+ /* Program (bit 0)=1 to disable internal pull-up on I2C2 */
+ prog_io |= OMAP3630_PRG_I2C2_PULLUPRESX;
+ omap_ctrl_writel(prog_io, OMAP343X_CONTROL_PROG_IO1);
+
+ prog_io = omap_ctrl_readl(OMAP36XX_CONTROL_PROG_IO2);
+ /* Program (bit 7)=1 to disable internal pull-up on I2C3 */
+ prog_io |= OMAP3630_PRG_I2C3_PULLUPRESX;
+ omap_ctrl_writel(prog_io, OMAP36XX_CONTROL_PROG_IO2);
+
+ prog_io = omap_ctrl_readl(OMAP36XX_CONTROL_PROG_IO_WKUP1);
+ /* Program (bit 5)=1 to disable internall pull-up on I2C4(SR) */
+ prog_io |= OMAP3630_PRG_SR_PULLUPRESX;
+ omap_ctrl_writel(prog_io, OMAP36XX_CONTROL_PROG_IO_WKUP1);
+ }
+
return omap_plat_register_i2c_bus(bus_id, clkrate, info, len);
}
diff --git a/arch/arm/plat-omap/include/plat/control.h
b/arch/arm/plat-omap/include/plat/control.h
index 2074473..9e58d8e 100644
--- a/arch/arm/plat-omap/include/plat/control.h
+++ b/arch/arm/plat-omap/include/plat/control.h
@@ -169,6 +169,9 @@
#define AM35XX_CONTROL_IP_SW_RESET (OMAP2_CONTROL_GENERAL + 0x0328)
#define AM35XX_CONTROL_IPSS_CLK_CTRL(OMAP2_CONTROL_GENERAL + 0x032C)
+/* 36xx-only CONTROL_GENERAL register offsets */
+#define OMAP36XX_CONTROL_PROG_IO2 (OMAP2_CONTROL_GENERAL + 0x0198)
+
/* 34xx PADCONF register offsets */
#define OMAP343X_PADCONF_ETK(i)(OMAP2_CONTROL_PADCONFS + 0x5a8
+ \
(i)*2)
@@ -200,6 +203,9 @@
#define OMAP343X_CONTROL_WKUP_DEBOBS3 (OMAP343X_CONTROL_GENERAL_WKUP + 0x014)
#define OMAP343X_CONTROL_WKUP_DEBOBS4 (OMAP343X_CONTROL_GENERAL_WKUP + 0x018)
+/* 36xx-only GENERAL_WKUP register offsets */
+#define OMAP36XX_CONTROL_PROG_IO_WKUP1 (OMAP343X_CONTROL_GENERAL_WKUP + 0x020)
+
/* 34xx D2D idle-related pins, handled by PM core */
#define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
#define OMAP3_PADCONF_SAD2D_IDLEACK0x254
@@ -250,6 +256,8 @@
#define OMAP2_PBIASLITEVMODE0 (1 << 0)
/* CONTROL_PROG_IO1 bits */
+#define OMAP3630_PRG_I2C2_PULLUPRESX(1 << 0)
+#define OMAP3630_PRG_I2C1_PULLUPRESX (1 << 19)
#define OMAP3630_PRG_SDMMC1_SPEEDCTRL (1 << 20)
/* CONTROL_IVA2_BOOTMOD bits */
@@ -257,6 +265,12 @@
#define OMAP3_IVA2_BOOTMOD_MASK(0xf << 0)
#define OMAP3_IVA2_BOOTMOD_IDLE(0x1 << 0)
+/* CONTROL_PROG_IO2 bits on omap3630 */
+#define OMAP3630_PRG_I2C3_PULLUPRESX(1 << 7)
+
+/* CONTROL_PROG_IO_WKUP1 bits on omap3630 */
+#define OMAP3630_PRG_SR_PULLUPRESX(1 << 5)
+
/* CONTROL_PADCONF_X bits */
#define OMAP3_PADCONF_WAKEUPEVENT0 (1 << 15)
#define OMAP3_PADCONF_WAKEUPENABLE0(1 << 14)
--
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
[PATCH 1/2] omap: Disable TWL4030/5030 I2C1/I2C4 internal pull-ups
This patch disables TWL4030/5030 I2C1 adn I2C4(SR) internal pull-up, to
use only the external HW resistor >=470 Ohm for the assured
functionality in HS mode.
While testing the I2C in High Speed mode, it was discovered that
without a proper pull-up resistor, there is data corruption during
multi-byte transfer. RTC(time_set) test case was used for testing.
>From the analysis done, it was concluded that ideally we need a
pull-up of 1.6k Ohm(recomended) or atleast 470 Ohm or greater for
assured performance in HS mode.
Signed-off-by: Moiz Sonasath
Signed-off-by: Allen Pais
---
drivers/mfd/twl-core.c | 13 +
include/linux/i2c/twl.h | 15 +++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 2a76065..35ae2ee 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -965,6 +965,7 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
int status;
unsignedi;
struct twl4030_platform_data*pdata = client->dev.platform_data;
+ u8 temp;
if (!pdata) {
dev_dbg(&client->dev, "no platform data?\n");
@@ -1032,6 +1033,18 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
goto fail;
}
+ /* Disable TWL4030/TWL5030 I2C Pull-up on I2C1 and I2C4(SR) interface.
+* Program I2C_SCL_CTRL_PU(bit 0)=0, I2C_SDA_CTRL_PU (bit 2)=0,
+* SR_I2C_SCL_CTRL_PU(bit 4)=0 and SR_I2C_SDA_CTRL_PU(bit 6)=0.
+*/
+
+ if (twl_class_is_4030()) {
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, &temp, REG_GPPUPDCTR1);
+ temp &= ~(SR_I2C_SDA_CTRL_PU | SR_I2C_SCL_CTRL_PU | \
+ I2C_SDA_CTRL_PU | I2C_SCL_CTRL_PU);
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
+ }
+
status = add_children(pdata, id->driver_data);
fail:
if (status < 0)
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index bf1c5be..fd95eca 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -239,6 +239,21 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset);
/*--*/
+/*Interface Bit Register (INTBR) offsets
+ *(Use TWL_4030_MODULE_INTBR)
+ */
+
+#define REG_GPPUPDCTR1 0x0F
+
+/*I2C1 and I2C4(SR) SDA/SCL pull-up control bits */
+
+#define I2C_SCL_CTRL_PUBIT(0)
+#define I2C_SDA_CTRL_PUBIT(2)
+#define SR_I2C_SCL_CTRL_PU BIT(4)
+#define SR_I2C_SDA_CTRL_PU BIT(6)
+
+/*--*/
+
/*
* Keypad register offsets (use TWL4030_MODULE_KEYPAD)
* ... SIH/interrupt only
--
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
[PATCH 2/2] DSPBRIDGE: Reclaim all pending buffer on resource cleanup
>From 6ed51fea16df51e88a25bda2b9908f0a43b86303 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo
Date: Tue, 16 Feb 2010 18:32:02 -0600
Subject: [PATCH] DSPBRIDGE: Reclaim all pending buffer on resource cleanup
Before in case of pending buffer while we try to close
a stream, it was doing only one reclaim, in the case there
were more pending buffer the second STRM_Close would also
fail, now all the pending buffers are reclaim.
Signed-off-by: Fernando Guzman Lugo
---
drivers/dsp/bridge/rmgr/drv.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 505f2b0..5a394da 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -461,6 +461,8 @@ DSP_STATUS DRV_RemoveAllSTRMResElements(HANDLE hPCtxt)
DSP_STATUS status = DSP_SOK;
struct STRM_RES_OBJECT *strm_res = NULL;
struct STRM_RES_OBJECT *strm_tmp = NULL;
+ struct STRM_INFO strm_info;
+ struct DSP_STREAMINFO user;
u8 **apBuffer = NULL;
u8 *pBufPtr;
u32 ulBytes;
@@ -474,17 +476,19 @@ DSP_STATUS DRV_RemoveAllSTRMResElements(HANDLE hPCtxt)
if (strm_res->uNumBufs) {
apBuffer = MEM_Alloc((strm_res->uNumBufs *
sizeof(u8 *)), MEM_NONPAGED);
- status = STRM_FreeBuffer(strm_res->hStream, apBuffer,
- strm_res->uNumBufs, pCtxt);
- kfree(apBuffer);
+ if (apBuffer) {
+ status = STRM_FreeBuffer(strm_res->hStream,
+ apBuffer, strm_res->uNumBufs, pCtxt);
+ kfree(apBuffer);
+ }
}
+ strm_info.pUser = &user;
+ user.uNumberBufsInStream = 0;
+ STRM_GetInfo(strm_res->hStream, &strm_info, sizeof(strm_info));
+ while (user.uNumberBufsInStream--)
+ STRM_Reclaim(strm_res->hStream, &pBufPtr, &ulBytes,
+(u32 *)&ulBufSize, &dwArg);
status = STRM_Close(strm_res->hStream, pCtxt);
- if (status == DSP_EPENDING) {
- status = STRM_Reclaim(strm_res->hStream,
- &pBufPtr, &ulBytes, (u32 *)&ulBufSize, &dwArg);
- if (DSP_SUCCEEDED(status))
- status = STRM_Close(strm_res->hStream, pCtxt);
- }
}
return status;
}
--
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 1/2] DSPBRIDGE: cleanup patch for DRV_RemoveAllSTRMResElements function
>From 718174a6ed1b54ce0120080a953d7f0a5ebb8d6d Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo
Date: Tue, 16 Feb 2010 18:14:26 -0600
Subject: [PATCH] DSPBRIDGE: cleanup patch for DRV_RemoveAllSTRMResElements
function
This patches clenaups the function DRV_RemoveAllSTRMResElements and
DRV_ProcFreeSTRMRes and it turns them into one function.
Signed-off-by: Fernando Guzman Lugo
---
drivers/dsp/bridge/rmgr/drv.c | 66
1 files changed, 20 insertions(+), 46 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 36bab9f..505f2b0 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -77,7 +77,6 @@ static DSP_STATUS RequestBridgeResourcesDSP(u32 dwContext,
s32 fRequest);
/* GPP PROCESS CLEANUP CODE */
static DSP_STATUS DRV_ProcFreeNodeRes(HANDLE hPCtxt);
-static DSP_STATUS DRV_ProcFreeSTRMRes(HANDLE hPCtxt);
extern enum NODE_STATE NODE_GetState(HANDLE hNode);
/* Allocate and add a node resource element
@@ -453,65 +452,40 @@ DSP_STATUSDRV_ProcRemoveSTRMResElement(HANDLE
hSTRMRes, HANDLE hPCtxt)
return DSP_SOK;
}
-/* Actual Stream De-Allocation */
-static DSP_STATUS DRV_ProcFreeSTRMRes(HANDLE hPCtxt)
+/* Release all Stream resources and its context
+* This is called from .bridge_release.
+*/
+DSP_STATUS DRV_RemoveAllSTRMResElements(HANDLE hPCtxt)
{
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
DSP_STATUS status = DSP_SOK;
- DSP_STATUS status1 = DSP_SOK;
+ struct STRM_RES_OBJECT *strm_res = NULL;
+ struct STRM_RES_OBJECT *strm_tmp = NULL;
u8 **apBuffer = NULL;
- struct STRM_RES_OBJECT *pSTRMList = NULL;
- struct STRM_RES_OBJECT *pSTRMRes = NULL;
u8 *pBufPtr;
u32 ulBytes;
u32 dwArg;
s32 ulBufSize;
- pSTRMList = pCtxt->pSTRMList;
- while (pSTRMList != NULL) {
- pSTRMRes = pSTRMList;
- pSTRMList = pSTRMList->next;
- if (pSTRMRes->uNumBufs != 0) {
- apBuffer = MEM_Alloc((pSTRMRes->uNumBufs *
+ strm_tmp = pCtxt->pSTRMList;
+ while (strm_tmp) {
+ strm_res = strm_tmp;
+ strm_tmp = strm_tmp->next;
+ if (strm_res->uNumBufs) {
+ apBuffer = MEM_Alloc((strm_res->uNumBufs *
sizeof(u8 *)), MEM_NONPAGED);
- status = STRM_FreeBuffer(pSTRMRes->hStream, apBuffer,
- pSTRMRes->uNumBufs, pCtxt);
+ status = STRM_FreeBuffer(strm_res->hStream, apBuffer,
+ strm_res->uNumBufs, pCtxt);
kfree(apBuffer);
}
- status = STRM_Close(pSTRMRes->hStream, pCtxt);
- if (DSP_FAILED(status)) {
- if (status == DSP_EPENDING) {
- status = STRM_Reclaim(pSTRMRes->hStream,
-&pBufPtr, &ulBytes,
-(u32 *)&ulBufSize, &dwArg);
- if (DSP_SUCCEEDED(status))
- status = STRM_Close(pSTRMRes->hStream,
- pCtxt);
-
- }
+ status = STRM_Close(strm_res->hStream, pCtxt);
+ if (status == DSP_EPENDING) {
+ status = STRM_Reclaim(strm_res->hStream,
+ &pBufPtr, &ulBytes, (u32 *)&ulBufSize, &dwArg);
+ if (DSP_SUCCEEDED(status))
+ status = STRM_Close(strm_res->hStream, pCtxt);
}
}
- return status1;
-}
-
-/* Release all Stream resources and its context
-* This is called from .bridge_release.
-*/
-DSP_STATUS DRV_RemoveAllSTRMResElements(HANDLE hPCtxt)
-{
- struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
- DSP_STATUS status = DSP_SOK;
- struct STRM_RES_OBJECT *pTempSTRMRes2 = NULL;
- struct STRM_RES_OBJECT *pTempSTRMRes = NULL;
-
- DRV_ProcFreeSTRMRes(pCtxt);
- pTempSTRMRes = pCtxt->pSTRMList;
- while (pTempSTRMRes != NULL) {
- pTempSTRMRes2 = pTempSTRMRes;
- pTempSTRMRes = pTempSTRMRes->next;
- kfree(pTempSTRMRes2);
- }
- pCtxt->pSTRMList = NULL;
return status;
}
--
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 0/2] DSPBRIDGE: fix and cleanup of stream resource cleanup
>From 6ed51fea16df51e88a25bda2b9908f0a43b86303 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo Date: Tue, 16 Feb 2010 18:35:58 -0600 Subject: [PATCH 0/2] DSPBRIDGE: fix and cleanup of stream resource cleanup This patch fixes an issue when there are still pending buffers for a stream at cleanup time, and it also cleanups DRV_RemoveAllSTRMResElements function. Fernando Guzman Lugo (2): DSPBRIDGE: cleanup patch for DRV_RemoveAllSTRMResElements function DSPBRIDGE: Reclaim all pending buffer on resource cleanup drivers/dsp/bridge/rmgr/drv.c | 72 ++-- 1 files changed, 25 insertions(+), 47 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
Re: [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths
On 2/12/2010 10:26 AM, Phil Carmody wrote: From: Phil Carmody We free in the tail cleanup, so don't free before jumping there. Signed-off-by: Phil Carmody --- [...] } + + /* paranoid - must be able to kfree this on remaining error paths */ + pProcObject->g_pszLastCoff = NULL; + do we need this? afaik it should be NULL at this point, because of kmalloc + memset (which btw should be replaced by kzalloc). i.e: MEM_AllocObject(pProcObject, struct PROC_OBJECT, PROC_SIGNATURE); -> MEM_Calloc(sizeof(Obj), MEM_NONPAGED); -> pMem = kmalloc(...) if (pMem) memset(pMem, 0, cBytes); /* Get the default executable for this board... */ DEV_GetDevType(hDevObject, (u32 *)&devType); pProcObject->uProcessor = devType; [...] Regards, Omar -- 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] DSPBRIDGE: Avoid inserting wrong elements to STRM list
On 2/10/2010 2:34 AM, Guzman Lugo, Fernando wrote: From 09260a0211d088d840d09c04380c8c9448c01ec4 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo Date: Wed, 10 Feb 2010 02:33:54 -0600 Subject: [PATCH] DSPBRIDGE: Avoid inserting wrong elements to STRM list This fixes a bug where in error case and after deleting a strm element (if allocated), the strm is still inserted as part of the process context allocated resources, this pointer is not valid and shouldn't be considered as part of valid resources. Signed-off-by: Fernando Guzman Lugo Acked-by: Omar Ramirez Luna Pushed to dspbridge - omar -- 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: [RESEND] [PATCH] DSPBRIDGE: Adding protection Resource cleanup linked lists
On 2/10/2010 2:32 AM, Guzman Lugo, Fernando wrote: Please discard previous one. Regards, Fernando. From 6bcdc02f6265246e385194433775e75db7ad44cf Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo Date: Wed, 10 Feb 2010 02:31:40 -0600 Subject: [PATCH] DSPBRIDGE: Adding protection Resource cleanup linked lists This patch protects the Resorce cleanup lists from concurrent access Signed-off-by: Fernando Guzman Lugo Removed wcd.c changes as functions affected doesn't exist. Acked-by: Omar Ramirez Luna Pushed to dspbridge - omar -- 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] dspbridge: Simplify Atoi() method (v2)
On 2/10/2010 1:58 AM, Andy Shevchenko wrote: From: Andy Shevchenko Try to use simple_strtoul() kernel native method instead. However, there are opened questions: - why type of Atoi() is s32 if the sign is used only to detect base? - should we really to check hex integers like DEAD0123h? - how many spaces could lead token? Signed-off-by: Andy Shevchenko Acked-by: Omar Ramirez Luna Pushed to dspbridge - omar -- 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] DSPBRIDGE: Add BRD_SLEEP_TRANSITION in PROC_GetState
On 2/9/2010 1:19 PM, Ramos Falcon, Ernesto wrote: From 40d5863c3d3f4091761fef8bff581d2a7b1f32fa Mon Sep 17 00:00:00 2001 From: Ernesto Ramos Date: Tue, 2 Feb 2010 20:30:19 -0600 Subject: [PATCH] DSPBRIDGE: Add BRD_SLEEP_TRANSITION in PROC_GetState. When PROC_GetState checks for BRD status it is not taking into account the state BRD_SLEEP_TRANSITION and it is returning DSP_EFAIL when this happens, which is wrong. This fix adds this check to return ProcStatus as PROC_RUNNING and status DSP_SOK when this happens. Signed-off-by: Ernesto Ramos Acked-by: Omar Ramirez Luna Pushed to dspbridge - omar -- 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: DSPBRIDGE: Replace page_address with kmap
On 2/8/2010 4:14 PM, Guzman Lugo, Fernando wrote: From 07880b3410ad19962d16ce1415f0423dfeed17da Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo Date: Fri, 5 Feb 2010 01:35:35 -0600 Subject: [PATCH] DSPBRIDGE: Replace page_address with kmap Replace page_address with kmap to get address in case of high mem allocation. Signed-off-by: Fernando Guzman Lugo Acked-by: Omar Ramirez Luna Pushed to dspbridge - omar -- 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 08/13] OMAP3/4 clock: split into per-chip family files
On Tue, 16 Feb 2010, Russell King - ARM Linux wrote: > On Tue, Feb 16, 2010 at 11:23:01AM -0800, Tony Lindgren wrote: > > Just to comment on the naming, we should call additional cpu options > > CONFIG_CPU_OMAP3630 etc instead of CONFIG_ARCH_OMAP to avoid confusion. > > Or CONFIG_SOC_OMAP3630. OMAP3630 is not a CPU type - it's a description > of the whole system. The CPU is just the processor and caches without > peripherals. Thanks; patch description has been updated to specify CONFIG_SOC_* instead. - 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 08/13] OMAP3/4 clock: split into per-chip family files
* Russell King - ARM Linux [100216 15:09]: > On Tue, Feb 16, 2010 at 11:23:01AM -0800, Tony Lindgren wrote: > > Just to comment on the naming, we should call additional cpu options > > CONFIG_CPU_OMAP3630 etc instead of CONFIG_ARCH_OMAP to avoid confusion. > > Or CONFIG_SOC_OMAP3630. OMAP3630 is not a CPU type - it's a description > of the whole system. The CPU is just the processor and caches without > peripherals. Sounds good to me. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/24] omap4: multi-omap: Allow build to work
On Tue, 16 Feb 2010, Santosh Shilimkar wrote: > The musb support is enable to omap3 platforms. For omap4 only board > support is available and the driver still isn't supported. > Because of this build with omap3_defconfig used for multi-omap > doesn't work on omap4430 sdp. > > This patch hacks the musb probe to keep the multi-omap build > working on omap4430 sdp > > Signed-off-by: Santosh Shilimkar > --- > drivers/usb/musb/musb_core.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c > index bcce8e8..13b1c4a 100644 > --- a/drivers/usb/musb/musb_core.c > +++ b/drivers/usb/musb/musb_core.c > @@ -2124,6 +2124,10 @@ static int __init musb_probe(struct platform_device > *pdev) > struct resource *iomem; > void __iomem*base; > > + /* FIXME: multi-omap build to work on omap4 */ > + if (cpu_is_omap44xx()) > + return 0; NAK. This will break musb compilation on all non-OMAP platforms. This is a major part of the reason why these cpu_is_omap*() calls should not go into any device driver. The right place for this kind of hack is in mach-omap2/usb-musb.c. Also, this should return an error, not pretend that it succeeded. It should also include a big fat WARN_ON() to reduce the risk that this temporary hack will be overlooked. > + > iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > if (!iomem || irq == 0) > return -ENODEV; > -- > 1.6.0.4 > - 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 15/24] omap4: clocks: Convert i2c clocks data to fclks
On Tue, 16 Feb 2010, Santosh Shilimkar wrote:
> In OMAP4 I2C module has only fclk control and iclks are controlled
> through hardware.(The OMAP4 clock tree autogeneration script has
> been updated accordingly.)
>
> CC:Paul Walmsley
> CC:Benoit Cousson
> Signed-off-by: Santosh Shilimkar
> ---
> arch/arm/mach-omap2/clock44xx_data.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock44xx_data.c
> b/arch/arm/mach-omap2/clock44xx_data.c
> index 86af31d..a69e8a0 100644
> --- a/arch/arm/mach-omap2/clock44xx_data.c
> +++ b/arch/arm/mach-omap2/clock44xx_data.c
> @@ -2665,10 +2665,10 @@ static struct omap_clk omap44xx_clks[] = {
> CLK(NULL, "gptimer9_ck", &gptimer9_ck,
> CK_443X),
> CLK("omap2_hdq.0", "ick", &hdq1w_ck,
> CK_443X),
> CLK(NULL, "hsi_ck", &hsi_ck,
> CK_443X),
> - CLK("i2c_omap.1", "ick", &i2c1_ck,
> CK_443X),
> - CLK("i2c_omap.2", "ick", &i2c2_ck,
> CK_443X),
> - CLK("i2c_omap.3", "ick", &i2c3_ck,
> CK_443X),
> - CLK("i2c_omap.4", "ick", &i2c4_ck,
> CK_443X),
You'll want to keep the above around, but use dummy_ck instead.
> + CLK("i2c_omap.1", "fck", &i2c1_ck,
> CK_443X),
> + CLK("i2c_omap.2", "fck", &i2c2_ck,
> CK_443X),
> + CLK("i2c_omap.3", "fck", &i2c3_ck,
> CK_443X),
> + CLK("i2c_omap.4", "fck", &i2c4_ck,
> CK_443X),
> CLK(NULL, "iss_ck", &iss_ck,
> CK_443X),
> CLK(NULL, "ivahd_ck", &ivahd_ck,
> CK_443X),
> CLK(NULL, "keyboard_ck", &keyboard_ck,
> CK_443X),
> --
> 1.6.0.4
>
- 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 18/24] omap4: clocks: Make i2c driver's clock calls OMAP4 compatible
On Tue, 16 Feb 2010, Santosh Shilimkar wrote:
> From: Abhijit Pagare
>
> The i2c driver has been adapted for the OMAP4 way of clock calls.
Please use dummy_ck here instead, etc. etc.
>
> Signed-off-by: Santosh Shilimkar
> Signed-off-by: Abhijit Pagare
> ---
> drivers/i2c/busses/i2c-omap.c | 29 -
> 1 files changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 89a156a..d4f6eda 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -260,11 +260,14 @@ static int __init omap_i2c_get_clocks(struct
> omap_i2c_dev *dev)
> {
> int ret;
>
> - dev->iclk = clk_get(dev->dev, "ick");
> - if (IS_ERR(dev->iclk)) {
> - ret = PTR_ERR(dev->iclk);
> - dev->iclk = NULL;
> - return ret;
> + /* OMAP4 iclk are hw controlled and no sw control is available */
> + if (!cpu_is_omap44xx()) {
> + dev->iclk = clk_get(dev->dev, "ick");
> + if (IS_ERR(dev->iclk)) {
> + ret = PTR_ERR(dev->iclk);
> + dev->iclk = NULL;
> + return ret;
> + }
> }
>
> dev->fclk = clk_get(dev->dev, "fck");
> @@ -285,15 +288,18 @@ static void omap_i2c_put_clocks(struct omap_i2c_dev
> *dev)
> {
> clk_put(dev->fclk);
> dev->fclk = NULL;
> - clk_put(dev->iclk);
> - dev->iclk = NULL;
> + if (!cpu_is_omap44xx()) {
> + clk_put(dev->iclk);
> + dev->iclk = NULL;
> + }
> }
>
> static void omap_i2c_unidle(struct omap_i2c_dev *dev)
> {
> WARN_ON(!dev->idle);
>
> - clk_enable(dev->iclk);
> + if (!cpu_is_omap44xx())
> + clk_enable(dev->iclk);
> clk_enable(dev->fclk);
> if (cpu_is_omap34xx()) {
> omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
> @@ -337,7 +343,8 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
> }
> dev->idle = 1;
> clk_disable(dev->fclk);
> - clk_disable(dev->iclk);
> + if (!cpu_is_omap44xx())
> + clk_disable(dev->iclk);
> }
>
> static int omap_i2c_init(struct omap_i2c_dev *dev)
> @@ -434,10 +441,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> internal_clk = 9600;
> else
> internal_clk = 4000;
> - /* FIXME: Remove this once clock framework is available*/
> - if (dev->rev >= OMAP_I2C_REV_ON_4430)
> - fclk_rate = 96000;
> - else
> fclk_rate = clk_get_rate(dev->fclk) / 1000;
>
> /* Compute prescaler divisor */
> --
> 1.6.0.4
>
- 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 16/24] omap4: Add i2c support on omap4 platform
Hello Santosh,
one general comment on this patch, before the specific comments. Rather
than adding more cpu_is_omap*() all over, please instead convert this code
to use flags passed in via platform_data. The I2C hwmod conversion
patches are one attempt to do that via the hwmod mechanism; you can use
that as an example of one way to do that with this driver.
On Tue, 16 Feb 2010, Santosh Shilimkar wrote:
> @@ -746,9 +814,12 @@ complete:
> if (dev->buf_len) {
> *dev->buf++ = w;
> dev->buf_len--;
> - /* Data reg from 2430 is 8 bit wide */
> + /* Data reg in 2430, omap3 and
> + * omap4 is 8 bit wide
> + */
The above comment needs to be fixed per CodingStyle.
> if (!cpu_is_omap2430() &&
> - !cpu_is_omap34xx()) {
> + !cpu_is_omap34xx() &&
> + !cpu_is_omap44xx()) {
> if (dev->buf_len) {
> *dev->buf++ = w >> 8;
> dev->buf_len--;
> @@ -786,9 +857,12 @@ complete:
> if (dev->buf_len) {
> w = *dev->buf++;
> dev->buf_len--;
> - /* Data reg from 2430 is 8 bit wide */
> + /* Data reg in 2430, omap3 and
> + * omap4 is 8 bit wide
> + */
The above comment needs to be fixed per CodingStyle.
> if (!cpu_is_omap2430() &&
> - !cpu_is_omap34xx()) {
> + !cpu_is_omap34xx() &&
> + !cpu_is_omap44xx()) {
> if (dev->buf_len) {
> w |= *dev->buf++ << 8;
> dev->buf_len--;
> @@ -897,6 +971,8 @@ omap_i2c_probe(struct platform_device *pdev)
>
> if (cpu_is_omap7xx())
> dev->reg_shift = 1;
> + else if (cpu_is_omap44xx())
> + dev->reg_shift = 0;
> else
> dev->reg_shift = 2;
>
> @@ -911,11 +987,16 @@ omap_i2c_probe(struct platform_device *pdev)
> if ((r = omap_i2c_get_clocks(dev)) != 0)
> goto err_iounmap;
>
> + if (cpu_is_omap44xx())
> + dev->regs = (u8 *) omap4_reg_map;
> + else
> + dev->regs = (u8 *) reg_map;
> +
> omap_i2c_unidle(dev);
>
> dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>
> - if (cpu_is_omap2430() || cpu_is_omap34xx()) {
> + if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) {
> u16 s;
>
> /* Set up the fifo size - Get total size */
> @@ -927,8 +1008,13 @@ omap_i2c_probe(struct platform_device *pdev)
>* size. This is to ensure that we can handle the status on int
>* call back latencies.
>*/
> - dev->fifo_size = (dev->fifo_size / 2);
> - dev->b_hw = 1; /* Enable hardware fixes */
> + if (dev->rev >= OMAP_I2C_REV_ON_4430) {
> + dev->fifo_size = 0;
> + dev->b_hw = 0; /* Enable hardware fixes */
> + } else {
> + dev->fifo_size = (dev->fifo_size / 2);
> + dev->b_hw = 1; /* Disable hardware fixes */
You've got the comments backwards here. b_hw = 1 means "enable hardware
fixes" as noted above.
> + }
> }
>
> /* reset ASAP, clearing any IRQs */
> --
> 1.6.0.4
>
- 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 1/4 RFC]OMAP2: Fix compile errors
"Varadarajan, Charulatha" writes:
> From: Rajendra Nayak
>
> There are few compile errors for OMAP2 which are fixed by this patch
>
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Charulatha V
> ---
> arch/arm/mach-omap2/board-2430sdp.c |2 +-
> arch/arm/mach-omap2/serial.c|1 +
> arch/arm/plat-omap/i2c.c|2 ++
> 3 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-2430sdp.c
> b/arch/arm/mach-omap2/board-2430sdp.c
> index d6f55ef..3f45d4b 100644
> --- a/arch/arm/mach-omap2/board-2430sdp.c
> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> @@ -146,7 +146,7 @@ static void __init omap_2430sdp_init_irq(void)
> {
> omap_board_config = sdp2430_config;
> omap_board_config_size = ARRAY_SIZE(sdp2430_config);
> - omap2_init_common_hw(NULL, NULL);
> + omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
This change is only needed in the PM branch. Please base this series
on mainline.
With our new OPP layer, the changes to init_common_hw() will be dropped
so this change will no longer be necessary.
Kevin
> omap_init_irq();
> omap_gpio_init();
> }
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index e7b874f..a686948 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -570,6 +570,7 @@ DEVICE_ATTR(sleep_timeout, 0644, sleep_timeout_show,
> sleep_timeout_store);
> #define DEV_CREATE_FILE(dev, attr) WARN_ON(device_create_file(dev, attr))
> #else
> static inline void omap_uart_idle_init(struct omap_uart_state *uart) {}
> +static void omap_uart_block_sleep(struct omap_uart_state *uart) {}
> #define DEV_CREATE_FILE(dev, attr)
> #endif /* CONFIG_PM */
>
> diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
> index fcb515d..6a617ca 100644
> --- a/arch/arm/plat-omap/i2c.c
> +++ b/arch/arm/plat-omap/i2c.c
> @@ -99,6 +99,8 @@ static void omap_i2c_set_wfc_mpu_wkup_lat(struct device
> *dev, int val)
> {
> omap_pm_set_max_mpu_wakeup_lat(dev, val);
> }
> +#else
> +static void omap_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int val) {}
> #endif
>
> static void __init omap_set_i2c_constraint_func(
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 08/13] OMAP3/4 clock: split into per-chip family files
On Tue, Feb 16, 2010 at 11:23:01AM -0800, Tony Lindgren wrote: > Just to comment on the naming, we should call additional cpu options > CONFIG_CPU_OMAP3630 etc instead of CONFIG_ARCH_OMAP to avoid confusion. Or CONFIG_SOC_OMAP3630. OMAP3630 is not a CPU type - it's a description of the whole system. The CPU is just the processor and caches without peripherals. -- 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/24] omap4: clocks: Make watchdog driver's clock calls OMAP4 compatible
Hello Abhijit, Santosh,
On Tue, 16 Feb 2010, Santosh Shilimkar wrote:
> The watchdog driver has been adapted for the OMAP4 way of clock calls.
> In OMAP4, WDT iclk are hw controlled and no sw control is available
>
> Signed-off-by: Abhijit Pagare
> ---
> drivers/watchdog/omap_wdt.c | 39 +++
> 1 files changed, 27 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> index c6aaf28..df9f714 100644
> --- a/drivers/watchdog/omap_wdt.c
> +++ b/drivers/watchdog/omap_wdt.c
> @@ -145,7 +145,9 @@ static int omap_wdt_open(struct inode *inode, struct file
> *file)
> if (test_and_set_bit(1, (unsigned long *)&(wdev->omap_wdt_users)))
> return -EBUSY;
>
> - clk_enable(wdev->ick);/* Enable the interface clock */
> + /* OMAP4 iclk are hw controlled and no sw control is available */
> + if (!cpu_is_omap44xx())
No new cpu_is_omap*() calls should be added to device drivers. The
intention is that drivers should be completely platform-independent. For
example, if DaVinci or some other platform uses the same watchdog IP, it
should be able to reuse this driver without dependencies on the OMAP core.
Instead, please use the dummy_ck mechanism, as mentioned earlier.
> + clk_enable(wdev->ick);/* Enable the interface clock */
> clk_enable(wdev->fck);/* Enable the functional clock */
>
> /* initialize prescaler */
> @@ -176,7 +178,9 @@ static int omap_wdt_release(struct inode *inode, struct
> file *file)
>
> omap_wdt_disable(wdev);
>
> - clk_disable(wdev->ick);
> + /* OMAP4 iclk are hw controlled and no sw control is available */
> + if (!cpu_is_omap44xx())
> + clk_disable(wdev->ick);
> clk_disable(wdev->fck);
> #else
> printk(KERN_CRIT "omap_wdt: Unexpected close, not stopping!\n");
> @@ -292,11 +296,14 @@ static int __devinit omap_wdt_probe(struct
> platform_device *pdev)
> wdev->omap_wdt_users = 0;
> wdev->mem = mem;
>
> - wdev->ick = clk_get(&pdev->dev, "ick");
> - if (IS_ERR(wdev->ick)) {
> - ret = PTR_ERR(wdev->ick);
> - wdev->ick = NULL;
> - goto err_clk;
> + /* OMAP4 iclk are hw controlled and no sw control is available */
> + if (!cpu_is_omap44xx()) {
> + wdev->ick = clk_get(&pdev->dev, "ick");
> + if (IS_ERR(wdev->ick)) {
> + ret = PTR_ERR(wdev->ick);
> + wdev->ick = NULL;
> + goto err_clk;
> + }
> }
> wdev->fck = clk_get(&pdev->dev, "fck");
> if (IS_ERR(wdev->fck)) {
> @@ -313,7 +320,9 @@ static int __devinit omap_wdt_probe(struct
> platform_device *pdev)
>
> platform_set_drvdata(pdev, wdev);
>
> - clk_enable(wdev->ick);
> + /* OMAP4 iclk are hw controlled and no sw control is available */
> + if (!cpu_is_omap44xx())
> + clk_enable(wdev->ick);
> clk_enable(wdev->fck);
>
> omap_wdt_disable(wdev);
> @@ -335,7 +344,9 @@ static int __devinit omap_wdt_probe(struct
> platform_device *pdev)
> /* autogate OCP interface clock */
> __raw_writel(0x01, wdev->base + OMAP_WATCHDOG_SYS_CONFIG);
>
> - clk_disable(wdev->ick);
> + /* OMAP4 iclk are hw controlled and no sw control is available */
> + if (!cpu_is_omap44xx())
> + clk_disable(wdev->ick);
> clk_disable(wdev->fck);
>
> omap_wdt_dev = pdev;
> @@ -350,8 +361,10 @@ err_ioremap:
> wdev->base = NULL;
>
> err_clk:
> - if (wdev->ick)
> - clk_put(wdev->ick);
> + /* OMAP4 iclk are hw controlled and no sw control is available */
> + if (!cpu_is_omap44xx())
> + if (wdev->ick)
> + clk_put(wdev->ick);
> if (wdev->fck)
> clk_put(wdev->fck);
> kfree(wdev);
> @@ -385,7 +398,9 @@ static int __devexit omap_wdt_remove(struct
> platform_device *pdev)
> release_mem_region(res->start, resource_size(res));
> platform_set_drvdata(pdev, NULL);
>
> - clk_put(wdev->ick);
> + /* OMAP4 iclk are hw controlled and no sw control is available */
> + if (!cpu_is_omap44xx())
> + clk_put(wdev->ick);
> clk_put(wdev->fck);
> iounmap(wdev->base);
>
> --
> 1.6.0.4
>
- 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 3/3] OMAP3: PM: Wakeup from TWL4030 keypad with OFF mode
"Premi, Sanjeev" writes: >> -Original Message- >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> Sent: Friday, February 05, 2010 3:22 AM >> To: Premi, Sanjeev >> Cc: linux-omap@vger.kernel.org >> Subject: Re: [PATCH 3/3] OMAP3: PM: Wakeup from TWL4030 >> keypad with OFF mode >> >> Sanjeev Premi writes: >> >> > This patch allows wakeup from TWL4030 keypad when >> > OFF mode is hit during suspend. >> > >> > Tested on OMAP3EVM. >> > >> > Signed-off-by: Sanjeev Premi >> >> The idea here looks good, but there is nothing realy EVM specific here >> AFAICT, and this exact code could be used on any other board using >> the T2 keypad, right? How about a common location? > > [sp] The EVM uses SYS_NIRQ for hooking up with the T2 keypad. Not > sure of everyone would be doing so. Also, PADCONFs are more > applicable for OMAP3, but T2 can be used with other processors > as well... > > I did initially inplement these functions in: > drivers/input/keyboard/twl4030_keypad.c > > ...but then moved to board specific file. I know at least SDP and EVM have these hooked up identically, so some common way to set them up would be preferred. Maybe a mach-omap2/t2-keypad.c that could be shared between various board files. The board files would still configure the IRQ line and the padconfs used. Kevin >> >> Also, after looking at this patch, I think the 'void *pstate' member >> of struct twl4030_keypad_data should be renamed to 'void *data' to >> be more clear that it's just a pointer. > > [sp] Will make the change. However, will wait for your response on the > earlier comment before re-submit. > > ~sanjeev > >> >> Kevin >> >> > > [snip]--[snip] -- 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 4/4] OMAP2/3 MMC: initial conversion to runtime PM
Adrian Hunter writes: > Kevin Hilman wrote: >> Convert the HSMMC driver to use the runtime PM layer. A notable >> aspect of this is that the use of the dev_attr data from the >> omap_hwmod allows the redaction of all of the integration-specific >> hacks inside this driver. Regulator control has not yet been >> converted; the driver still uses the platform_data set_power hook. >> >> In converting to runtime PM layer, the clock frameworks is no longer >> used for fclk and iclk. Instead, the runtime PM get and put functions >> are used. These result in calls into the OMAP runtime PM core which >> internally uses the omap_device API to disable/re-enable the device. >> (Note that the 2430 debounce clock is not currently handled here, >> only the fclk and iclk are managed.) >> >> In addition, the context_loss tracking has been removed from the >> driver and is now handled by omap_device + runtime PM core. The >> driver's ->runtime_suspend() hook will be called before device is >> disabled, and the driver's ->runtime_resume() hook will be called if >> context has been lost. >> >> Based on an initial conversion of this driver to use omap_device by >> by Paul Walmsely: http://marc.info/?l=linux-omap&m=124419789124570&w=2 >> and then converted to use runtime PM API instead of omap_device API. >> >> The omap_hsmmc driver has some hacks in this version to compensate for >> the fact that the main runtime PM core prevents runtime transitions >> during suspend. This prevens us from using common hooks for runtime >> PM and static PM. Current workaround is to hack in some extra put/get >> calls in the suspend/resume path while this issue is being discussed >> on linux-pm. >> >> Cc: Paul Walmsley >> Signed-off-by: Kevin Hilman >> --- >> arch/arm/mach-omap2/devices.c | 152 +-- >> arch/arm/mach-omap2/hsmmc.c | 12 +- >> arch/arm/plat-omap/include/plat/mmc.h |5 + >> drivers/mmc/host/omap_hsmmc.c | 226 >> +++-- >> 4 files changed, 176 insertions(+), 219 deletions(-) > > Why is PM runtime not simply PM? > > Can pm_runtime_put_sync() and pm_runtime_get_sync() have less obscure names? The runtime PM names are not my creation. This is a new PM framework in mainline that I am taking advantage of. See: http://elinux.org/OMAP_Power_Management#Run-time_PM 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 09/24] omap4: clocks: Make mcbsp driver's clock calls OMAP4 compatible
Hello Abhijit, Santosh,
On Tue, 16 Feb 2010, Santosh Shilimkar wrote:
> The mcbsp driver has been adapted for the OMAP4 way of clock calls.
> In OMAP4, the iclk are hw controlled and no sw control is available
>
> Signed-off-by: Abhijit Pagare
> Signed-off-by: Santosh Shilimkar
> ---
> arch/arm/plat-omap/mcbsp.c | 13 -
> 1 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
> index 473be3d..72b9694 100644
> --- a/arch/arm/plat-omap/mcbsp.c
> +++ b/arch/arm/plat-omap/mcbsp.c
> @@ -1314,11 +1314,14 @@ static int __devinit omap_mcbsp_probe(struct
> platform_device *pdev)
> mcbsp->dma_rx_sync = pdata->dma_rx_sync;
> mcbsp->dma_tx_sync = pdata->dma_tx_sync;
>
> - mcbsp->iclk = clk_get(&pdev->dev, "ick");
> - if (IS_ERR(mcbsp->iclk)) {
> - ret = PTR_ERR(mcbsp->iclk);
> - dev_err(&pdev->dev, "unable to get ick: %d\n", ret);
> - goto err_iclk;
> + /* OMAP4 iclk are hw controlled and no sw control is available */
> + if (!cpu_is_omap44xx()) {
Please use dummy_ck for this, rather than modifying plat-omap/mcbsp.c.
> + mcbsp->iclk = clk_get(&pdev->dev, "ick");
> + if (IS_ERR(mcbsp->iclk)) {
> + ret = PTR_ERR(mcbsp->iclk);
> + dev_err(&pdev->dev, "unable to get ick: %d\n", ret);
> + goto err_iclk;
> + }
> }
>
> mcbsp->fclk = clk_get(&pdev->dev, "fck");
> --
> 1.6.0.4
>
- 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 08/24] omap4: clocks: Make Uart driver's clock calls OMAP4 compatible
Hello Abhijit, Santosh,
On Tue, 16 Feb 2010, Santosh Shilimkar wrote:
> From: Abhijit Pagare
>
> The uart driver has been adapted for the OMAP4 way of clock calls.
This patch needs some revision.
According to the 4430 TRM ES1.0 Rev A section 23.3.3 "UART/IrDA/CIR
Integration", and cross-referencing it with clock44xx_data.c, these clocks
which are marked as interface clocks should really be marked as functional
clocks. For example, in the clock data, they descend from per_48_fclk,
which according to the TRM diagram, indicates that they are functional
clocks. The TRM diagram also names these clocks "UARTx_FCLK" rather than
"UARTx_CK", perhaps this naming should be preserved?
Also, rather than adding an extra cpu_is_omap*() conditional in the code
for a missing clock, please use the dummy_ck functionality. Santosh will
need this for OMAP4 I2C anyway; this appears to be another example where
this is needed.
- Paul
>
> Signed-off-by: Abhijit Pagare
> ---
> arch/arm/mach-omap2/serial.c | 24
> 1 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index b79bc89..97859b0 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -257,7 +257,8 @@ static inline void omap_uart_enable_clocks(struct
> omap_uart_state *uart)
> return;
>
> clk_enable(uart->ick);
> - clk_enable(uart->fck);
> + if (!cpu_is_omap44xx())
> + clk_enable(uart->fck);
> uart->clocked = 1;
> omap_uart_restore_context(uart);
> }
> @@ -272,7 +273,8 @@ static inline void omap_uart_disable_clocks(struct
> omap_uart_state *uart)
> omap_uart_save_context(uart);
> uart->clocked = 0;
> clk_disable(uart->ick);
> - clk_disable(uart->fck);
> + if (!cpu_is_omap44xx())
> + clk_disable(uart->fck);
> }
>
> static void omap_uart_enable_wakeup(struct omap_uart_state *uart)
> @@ -669,18 +671,24 @@ void __init omap_serial_early_init(void)
> continue;
> }
>
> - sprintf(name, "uart%d_ick", i+1);
> + if (!cpu_is_omap44xx())
> + sprintf(name, "uart%d_ick", i+1);
> + else
> + sprintf(name, "uart%d_ck", i+1);
> uart->ick = clk_get(NULL, name);
> if (IS_ERR(uart->ick)) {
> printk(KERN_ERR "Could not get uart%d_ick\n", i+1);
> uart->ick = NULL;
> }
>
> - sprintf(name, "uart%d_fck", i+1);
> - uart->fck = clk_get(NULL, name);
> - if (IS_ERR(uart->fck)) {
> - printk(KERN_ERR "Could not get uart%d_fck\n", i+1);
> - uart->fck = NULL;
> + if (!cpu_is_omap44xx()) {
> + sprintf(name, "uart%d_fck", i+1);
> + uart->fck = clk_get(NULL, name);
> + if (IS_ERR(uart->fck)) {
> + printk(KERN_ERR "Could not get uart%d_fck\n",
> + i+1);
> + uart->fck = NULL;
> + }
> }
>
> /* FIXME: Remove this once the clkdev is ready */
> --
> 1.6.0.4
>
- 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/RFC 4/4] OMAP2/3 MMC: initial conversion to runtime PM
> err_irq:
> mmc_host_disable(host->mmc);
> - clk_disable(host->iclk);
> + pm_runtime_suspend(host->dev);
Why not pm_runtime_put_sync() here? It can replace the calls:
mmc_host_disable(host->mmc);
clk_disable(host->iclk);
> clk_put(host->fclk);
> clk_put(host->iclk);
> +
> if (host->got_dbclk) {
> clk_disable(host->dbclk);
> clk_put(host->dbclk);
> @@ -2216,7 +2164,8 @@ static int omap_hsmmc_remove(struct platform_device
> *pdev)
> flush_scheduled_work();
>
> mmc_host_disable(host->mmc);
> - clk_disable(host->iclk);
> + pm_runtime_suspend(host->dev);
> +
Ditto
> clk_put(host->fclk);
> clk_put(host->iclk);
> if (host->got_dbclk) {
> @@ -2272,7 +2221,7 @@ static int omap_hsmmc_suspend(struct device *dev)
> OMAP_HSMMC_WRITE(host->base, HCTL,
> OMAP_HSMMC_READ(host->base, HCTL) & ~SDBP);
> mmc_host_disable(host->mmc);
> - clk_disable(host->iclk);
> +
> if (host->got_dbclk)
> clk_disable(host->dbclk);
> } else {
> @@ -2287,6 +2236,11 @@ static int omap_hsmmc_suspend(struct device *dev)
> mmc_host_disable(host->mmc);
> }
>
> + /*
> + * HACK: "extra" put to compensate for DPM core keeping
> + * runtime PM disabled. -- khilman
> + */
> + pm_runtime_put_sync(host->dev);
> }
> return ret;
> }
> @@ -2302,12 +2256,14 @@ static int omap_hsmmc_resume(struct device *dev)
> return 0;
>
> if (host) {
> - ret = clk_enable(host->iclk);
> - if (ret)
> - goto clk_en_err;
> + /*
> + * HACK: "extra" get to compensate for DPM core keeping
> + * runtime PM disabled. -- khilman
> + */
> + pm_runtime_get_sync(host->dev);
>
> if (mmc_host_enable(host->mmc) != 0) {
> - clk_disable(host->iclk);
> + pm_runtime_suspend(host->dev);
> goto clk_en_err;
> }
>
> @@ -2346,9 +2302,37 @@ clk_en_err:
> #define omap_hsmmc_resumeNULL
> #endif
>
> +/* called just before device is disabled */
> +static int omap_hsmmc_runtime_suspend(struct device *dev)
> +{
> + struct omap_hsmmc_host *host;
> +
> + dev_dbg(dev, "%s\n", __func__);
> +
> + host = platform_get_drvdata(to_platform_device(dev));
> + omap_hsmmc_context_save(host);
The context_save fn is now empty. How does it help here?
> +
> + return 0;
> +}
> +
> +/* called after device is (re)enabled, ONLY if context was lost */
> +static int omap_hsmmc_runtime_resume(struct device *dev)
> +{
> + struct omap_hsmmc_host *host;
> +
> + dev_dbg(dev, "%s\n", __func__);
> +
> + host = platform_get_drvdata(to_platform_device(dev));
> + omap_hsmmc_context_restore(host);
> +
> + return 0;
> +}
> +
> static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
> .suspend= omap_hsmmc_suspend,
> .resume = omap_hsmmc_resume,
> + .runtime_suspend = omap_hsmmc_runtime_suspend,
> + .runtime_resume = omap_hsmmc_runtime_resume,
> };
>
> static struct platform_driver omap_hsmmc_driver = {
> --
> 1.6.6
>
> --
> 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 05/24] omap4: Add needed IRQ line into irqs.h
Hello Santosh, On Tue, 16 Feb 2010, Santosh Shilimkar wrote: > This patch adds DSS, keyboard and ducati irq > entries in irqs.h > > Ones omap4 hwmod is pushed on mainlie, all the > irqs lines data would be availabe. Instead of this patch, why not just replace the current file with the one from the OMAP4 autogeneration scripts? I don't see why the IRQ macros should depend on hwmod availability, and it would be better to have the correct IRQ data appear in one patch, rather than having to review and approve several smaller incremental patches over time. The same reasoning should apply the DMA data also, I'd think. - Paul > > Signed-off-by: Santosh Shilimkar > --- > arch/arm/plat-omap/include/plat/irqs.h |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/plat-omap/include/plat/irqs.h > b/arch/arm/plat-omap/include/plat/irqs.h > index e8205c1..e2fbd74 100644 > --- a/arch/arm/plat-omap/include/plat/irqs.h > +++ b/arch/arm/plat-omap/include/plat/irqs.h > @@ -385,6 +385,7 @@ > #define INT_44XX_GPTIMER11 (47 + IRQ_GIC_START) > #define INT_44XX_GPTIMER12 (95 + IRQ_GIC_START) > #define INT_44XX_SHA1MD5 (51 + IRQ_GIC_START) > +#define INT_44XX_DSS_DSI1(53 + IRQ_GIC_START) > #define INT_44XX_I2C1_IRQ(56 + IRQ_GIC_START) > #define INT_44XX_I2C2_IRQ(57 + IRQ_GIC_START) > #define INT_44XX_HDQ_IRQ (58 + IRQ_GIC_START) > @@ -405,6 +406,7 @@ > #define INT_44XX_MCBSP4_IRQ_TX (81 + IRQ_GIC_START) > #define INT_44XX_MCBSP4_IRQ_RX (82 + IRQ_GIC_START) > #define INT_44XX_MMC_IRQ (83 + IRQ_GIC_START) > +#define INT_44XX_DSS_DSI2(84 + IRQ_GIC_START) > #define INT_44XX_MMC2_IRQ(86 + IRQ_GIC_START) > #define INT_44XX_MCBSP2_IRQ_TX (89 + IRQ_GIC_START) > #define INT_44XX_MCBSP2_IRQ_RX (90 + IRQ_GIC_START) > @@ -442,7 +444,10 @@ > #define INT_44XX_PARTHASH_IRQ(79 + IRQ_GIC_START) > #define INT_44XX_MMC3_IRQ(94 + IRQ_GIC_START) > #define INT_44XX_MMC4_IRQ(96 + IRQ_GIC_START) > +#define INT_44XX_DUCATI_MMU_IRQ (100 + IRQ_GIC_START) > #define INT_44XX_MCPDM_IRQ (112 + IRQ_GIC_START) > +#define INT_4XX_DSS_HDMI (101 + IRQ_GIC_START) > +#define INT_44XX_KBD_CTL (120 + IRQ_GIC_START) > > /* Max. 128 level 2 IRQs (OMAP1610), 192 GPIOs (OMAP730/850) and > * 16 MPUIO lines */ > -- > 1.6.0.4 > - 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 02/24] omap2/3/4: ioremap omap_globals module
Hello Santosh,
some comments:
On Tue, 16 Feb 2010, Santosh Shilimkar wrote:
> This is a clean-up patch towards dynamic allocation of IO space
> instead of using harcoded macros to calculate virtual addresses.
>
> Also update the sdrc, prcm, tap and control module to
> allocate iospace dynamically
>
> As per Tony's suggestion V2 version drops tap changes
> becasue ioremap uses cpu_is_omap2420() and cpu_is_omap2430(),
> so we can't use that for setting tap_base. Hence ioremap()
> won't work for tap until omap2_check_revision() is done
>
> Signed-off-by: Santosh Shilimkar
> CC: Kevin Hilman
> CC: Tony Lindgren
> ---
> arch/arm/mach-omap2/control.c|6 -
> arch/arm/mach-omap2/prcm.c | 16 ++--
> arch/arm/mach-omap2/sdrc.c | 11 +++-
> arch/arm/plat-omap/common.c | 38
> +++---
> arch/arm/plat-omap/include/plat/common.h | 12
> 5 files changed, 52 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
> index cdd1f35..43f8a33 100644
> --- a/arch/arm/mach-omap2/control.c
> +++ b/arch/arm/mach-omap2/control.c
> @@ -140,7 +140,11 @@ static struct omap3_control_regs control_context;
>
> void __init omap2_set_globals_control(struct omap_globals *omap2_globals)
> {
> - omap2_ctrl_base = omap2_globals->ctrl;
> + /* Static mapping, never released */
> + if (omap2_globals->ctrl) {
> + omap2_ctrl_base = ioremap(omap2_globals->ctrl, SZ_4K);
> + WARN_ON(!omap2_ctrl_base);
> + }
> }
>
> void __iomem *omap_ctrl_base_get(void)
> diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
> index e8e121a..338d5f6 100644
> --- a/arch/arm/mach-omap2/prcm.c
> +++ b/arch/arm/mach-omap2/prcm.c
> @@ -279,9 +279,19 @@ int omap2_cm_wait_idlest(void __iomem *reg, u32 mask,
> const char *name)
>
> void __init omap2_set_globals_prcm(struct omap_globals *omap2_globals)
> {
> - prm_base = omap2_globals->prm;
> - cm_base = omap2_globals->cm;
> - cm2_base = omap2_globals->cm2;
> + /* Static mapping, never released */
> + if (omap2_globals->prm) {
> + prm_base = ioremap(omap2_globals->prm, SZ_8K);
> + WARN_ON(!prm_base);
> + }
> + if (omap2_globals->cm) {
> + cm_base = ioremap(omap2_globals->cm, SZ_8K);
> + WARN_ON(!cm_base);
> + }
> + if (omap2_globals->cm2) {
> + cm2_base = ioremap(omap2_globals->cm2, SZ_8K);
> + WARN_ON(!cm2_base);
> + }
> }
>
> #ifdef CONFIG_ARCH_OMAP3
> diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
> index cbfbd14..4c65f56 100644
> --- a/arch/arm/mach-omap2/sdrc.c
> +++ b/arch/arm/mach-omap2/sdrc.c
> @@ -119,8 +119,15 @@ int omap2_sdrc_get_params(unsigned long r,
>
> void __init omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
> {
> - omap2_sdrc_base = omap2_globals->sdrc;
> - omap2_sms_base = omap2_globals->sms;
> + /* Static mapping, never released */
> + if (omap2_globals->sdrc) {
> + omap2_sdrc_base = ioremap(omap2_globals->sdrc, SZ_64K);
> + WARN_ON(!omap2_sdrc_base);
> + }
> + if (omap2_globals->sms) {
> + omap2_sms_base = ioremap(omap2_globals->sms, SZ_64K);
> + WARN_ON(!omap2_sms_base);
> + }
> }
>
> /**
> diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
> index 4f29e8c..ee9499e 100644
> --- a/arch/arm/plat-omap/common.c
> +++ b/arch/arm/plat-omap/common.c
> @@ -256,11 +256,11 @@ static void __init __omap2_set_globals(struct
> omap_globals *omap2_globals)
> static struct omap_globals omap242x_globals = {
> .class = OMAP242X_CLASS,
> .tap= OMAP2_L4_IO_ADDRESS(0x48014000),
> - .sdrc = OMAP2_L3_IO_ADDRESS(OMAP2420_SDRC_BASE),
> - .sms= OMAP2_L3_IO_ADDRESS(OMAP2420_SMS_BASE),
> - .ctrl = OMAP2_L4_IO_ADDRESS(OMAP2420_CTRL_BASE),
> - .prm= OMAP2_L4_IO_ADDRESS(OMAP2420_PRM_BASE),
> - .cm = OMAP2_L4_IO_ADDRESS(OMAP2420_CM_BASE),
> + .sdrc = OMAP2420_SDRC_BASE,
> + .sms= OMAP2420_SMS_BASE,
> + .ctrl = OMAP2420_CTRL_BASE,
> + .prm= OMAP2420_PRM_BASE,
> + .cm = OMAP2420_CM_BASE,
> .uart1_phys = OMAP2_UART1_BASE,
> .uart2_phys = OMAP2_UART2_BASE,
> .uart3_phys = OMAP2_UART3_BASE,
> @@ -277,11 +277,11 @@ void __init omap2_set_globals_242x(void)
> static struct omap_globals omap243x_globals = {
> .class = OMAP243X_CLASS,
> .tap= OMAP2_L4_IO_ADDRESS(0x4900a000),
> - .sdrc = OMAP2_L3_IO_ADDRESS(OMAP243X_SDRC_BASE),
> - .sms= OMAP2_L3_IO_ADDRESS(OMAP243X_SMS_BASE),
> - .ctrl = OMAP2_L4_IO_ADDRESS(OMAP243X_CTRL_BASE),
> - .prm= OMAP2_L4_IO_ADDRESS(OMAP2430_PRM_BASE),
> - .cm = OMAP2_L4_IO_ADDRESS(OMAP2430_CM_BASE),
> + .sdrc = OMAP243X_SDRC_BASE,
> + .sms= (
Re: [PATCH v2 08/13] OMAP3/4 clock: split into per-chip family files
On Tue, 16 Feb 2010, Tony Lindgren wrote: > * Paul Walmsley [100215 16:56]: > > > > clock34xx_data.c now contains data for the OMAP34xx family, the > > OMAP36xx family, and the OMAP3517 family, so rename it to > > clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the > > chip family-specific clock functions to clock34xx.c, clock36xx.c, or > > clock3517.c, as appropriate. So now "clock3xxx.*" refers to the OMAP3 > > superset. > > > > The main goal here is to prepare to compile chip family-specific clock > > functions only for kernel builds that target that chip family. To get to > > that point, we also need to add CONFIG_ARCH_* options for those other > > chip families; that will be done in a future patch, planned for 2.6.35. > > Just to comment on the naming, we should call additional cpu options > CONFIG_CPU_OMAP3630 etc instead of CONFIG_ARCH_OMAP to avoid confusion. > > I thought about renaming CONFIG_ARCH_OMAP2420 and CONFIG_ARCH_OMAP2430 > into CONFIG_CPU_OMAP2420 and CONFIG_CPU_OMAP2430, but as it covers > a bunch of drivers too I've postponed that to 2.6.35. Thanks, I've updated the patch description accordingly to reference CONFIG_CPU_* rather than CONFIG_ARCH_*. - 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 2/3]: Adds support for FIFO
This patch is also word-wrapped; which also seriously confuses
patchwork. Please resend patches 2 and 3 from the series also. I'll
pick up all three.
g.
On Wed, Feb 3, 2010 at 3:21 AM, Hemanth V wrote:
> From 5faa83f37c0aaa73e2a03780d2b1dfe9469d1e2e Mon Sep 17 00:00:00 2001
> From: Hemanth V
> Date: Wed, 2 Dec 2009 18:13:13 +0530
> Subject: [PATCH] Adds support for FIFO and auto chip select mode
>
> 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.
>
> Auto chip select mode can be enabled by setting force_cs_mode
> to zero
>
> Signed-off-by: Hemanth V
> ---
> drivers/spi/omap2_mcspi.c | 338
> -
> 1 files changed, 302 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c index
> 121cdd2..ce02f50 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -37,10 +37,11 @@
>
> #include
> #include
> +#include
>
>
> #define OMAP2_MCSPI_MAX_FREQ 4800
> -
> +#define OMAP2_MCSPI_MAX_FIFODEPTH 64
> /* OMAP2 has 3 SPI controllers, while OMAP3 has 4 */
> #define OMAP2_MCSPI_MAX_CTRL 4
>
> @@ -52,6 +53,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_CHCONF0 0x2c
> @@ -88,11 +90,15 @@
> #define OMAP2_MCSPI_CHCONF_IS BIT(18)
> #define OMAP2_MCSPI_CHCONF_TURBO BIT(19)
> #define OMAP2_MCSPI_CHCONF_FORCE BIT(20)
> +#define OMAP2_MCSPI_CHCONF_FFET BIT(27)
> +#define OMAP2_MCSPI_CHCONF_FFER BIT(28)
>
> #define OMAP2_MCSPI_CHSTAT_RXS BIT(0)
> #define OMAP2_MCSPI_CHSTAT_TXS BIT(1)
> #define OMAP2_MCSPI_CHSTAT_EOT BIT(2)
>
> +#define OMAP2_MCSPI_IRQ_EOW BIT(17)
> +
> #define OMAP2_MCSPI_CHCTRL_EN BIT(0)
>
> #define OMAP2_MCSPI_WAKEUPENABLE_WKEN BIT(0)
> @@ -128,6 +134,10 @@ struct omap2_mcspi {
> unsigned long phys;
> /* SPI1 has 4 channels, while SPI2 has 2 */
> struct omap2_mcspi_dma *dma_channels;
> + u8 mcspi_mode;
> + u8 dma_mode;
> + u8 force_cs_mode;
> + u16 fifo_depth;
> };
>
> struct omap2_mcspi_cs {
> @@ -151,6 +161,37 @@ struct omap2_mcspi_regs {
>
> static struct omap2_mcspi_regs omap2_mcspi_ctx[OMAP2_MCSPI_MAX_CTRL];
>
> +#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 { \
> @@ -221,6 +262,39 @@ static void omap2_mcspi_set_dma_req(const struct
> spi_device *spi,
> mcspi_write_chconf0(spi, 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 = ®_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,
Re: PATCH[V2 1/3]: Update Platform files for SPI
On Tue, Feb 16, 2010 at 7:38 AM, Hemanth V wrote: >> * Tony Lindgren [100209 15:03]: >>> * Grant Likely [100209 14:38]: >>> > On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren wrote: >>> > > * Hemanth V [100203 02:19]: >>> > >> From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 >>> > >> From: Hemanth V >>> > >> Date: Fri, 27 Nov 2009 14:22:30 +0530 >>> > >> Subject: [PATCH] Update platform files >>> > >> >>> > >> This patch updates platform files for >>> > >> fifo, slave support >>> > >> >>> > >> Signed-off-by: Hemanth V >>> > > >>> > > This should get merged via the spi-devel list with the other patches. >>> > > >>> > > Acked-by: Tony Lindgren >>> > >>> > Personally, I prefer not to carry arch/* changes in my next-spi >>> > branch, since it means that my pull requests are less obvious for >>> > Linus and there is greater chance of conflict. >>> > >>> > But if you still really want me to merge it through my tree, (or if >>> > getting the patches out of order will break things) then I'll pick it >>> > up. Just let me know. >>> >>> OK, if you ack it, I'll add the header into omap for-next. That >>> might break git bisect for some configurations depending in which >>> order the patches get pulled by Linus.. >>> >>> I guess eventually this header should not live under plat. >> >> Hemanth, the patch is missing line breaks so it won't apply: >> >> http://patchwork.kernel.org/patch/76675/ >> >> Please resend, I'm not editing patches manually any longer thanks. >> >> Regards, >> >> Tony >> > Pl find the patches attached, hopefully it doesnot get corrupted this > time This one is okay, and I've got it in my tree, but I need patches 2 and 3 resent also. Thanks, g. -- 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: DSPBRIDGE: Reclaim all pending buffer on resource cleanup
>-Original Message-
>From: Ramirez Luna, Omar
>Sent: Tuesday, February 16, 2010 12:13 PM
>To: Guzman Lugo, Fernando
>Cc: linux-omap; Hiroshi Doyu; Ameya Palande; Felipe Contreras
>Subject: Re: DSPBRIDGE: Reclaim all pending buffer on resource cleanup
>
>Hi,
>
>On 2/8/2010 4:20 PM, Guzman Lugo, Fernando wrote:
>> From 727c83cd8b7e4aca51b214412eaa1b95cde6e4ea Mon Sep 17 00:00:00 2001
>> From: Fernando Guzman Lugo
>> Date: Tue, 2 Feb 2010 20:38:10 -0600
>> Subject: [PATCH] DSPBRIDGE: Reclaim all pending buffer on resource
>cleanup
>>
>> Before in case of pending buffer while we try to close
>> a stream, it was doing only one reclaim, in the case there
>> were more pending buffer the second STRM_Close would also
>> fail, now all the pending buffers are reclaim.
>>
>> Signed-off-by: Fernando Guzman Lugo
>> ---
>
>Shouldn't this be like?
>Patch 1: Fix
>Patch 2: code enhancement
>
>that said, isn't this missing a STRM_Close? (look below)
Yes, you re right, that is a mistake. I will send it again.
Regards,
Fernando.
>
>> drivers/dsp/bridge/rmgr/drv.c | 37 --
>---
>> 1 files changed, 16 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/dsp/bridge/rmgr/drv.c
>b/drivers/dsp/bridge/rmgr/drv.c
>> index edd8e97..660f375 100644
>> --- a/drivers/dsp/bridge/rmgr/drv.c
>> +++ b/drivers/dsp/bridge/rmgr/drv.c
>> @@ -458,40 +458,35 @@ static DSP_STATUS DRV_ProcFreeSTRMRes(HANDLE
>hPCtxt)
>> {
>> struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
>> DSP_STATUS status = DSP_SOK;
>> -DSP_STATUS status1 = DSP_SOK;
>> u8 **apBuffer = NULL;
>> -struct STRM_RES_OBJECT *pSTRMList = NULL;
>> struct STRM_RES_OBJECT *pSTRMRes = NULL;
>> +struct STRM_INFO strm_info;
>> +struct DSP_STREAMINFO user;
>> u8 *pBufPtr;
>> u32 ulBytes;
>> u32 dwArg;
>> s32 ulBufSize;
>>
>> -pSTRMList = pCtxt->pSTRMList;
>> -while (pSTRMList != NULL) {
>> -pSTRMRes = pSTRMList;
>> -pSTRMList = pSTRMList->next;
>> -if (pSTRMRes->uNumBufs != 0) {
>> -apBuffer = MEM_Alloc((pSTRMRes->uNumBufs *
>> -sizeof(u8 *)), MEM_NONPAGED);
>> +pSTRMRes = pCtxt->pSTRMList;
>> +while (pSTRMRes) {
>> +if (pSTRMRes->uNumBufs) {
>> +apBuffer = MEM_Alloc(pSTRMRes->uNumBufs *
>> +sizeof(u8 *), MEM_NONPAGED);
>> +if (!apBuffer)
>> +return DSP_EMEMORY;
>> status = STRM_FreeBuffer(pSTRMRes->hStream, apBuffer,
>> pSTRMRes->uNumBufs, pCtxt);
>> MEM_Free(apBuffer);
>> }
>> -status = STRM_Close(pSTRMRes->hStream, pCtxt);
>> -if (DSP_FAILED(status)) {
>> -if (status == DSP_EPENDING) {
>> -status = STRM_Reclaim(pSTRMRes->hStream,
>> -&pBufPtr,&ulBytes,
>> - (u32 *)&ulBufSize,&dwArg);
>> -if (DSP_SUCCEEDED(status))
>> -status = STRM_Close(pSTRMRes->hStream,
>> -pCtxt);
>> +strm_info.pUser =&user;
>> +user.uNumberBufsInStream = 0;
>> +STRM_GetInfo(pSTRMRes->hStream,&strm_info, sizeof(strm_info));
>> +while (strm_info.pUser->uNumberBufsInStream--)
>> +STRM_Reclaim(pSTRMRes->hStream,&pBufPtr,&ulBytes,
>> + (u32 *)&ulBufSize,&dwArg);
>>
>
>Here.
>
>> -}
>> -}
>> }
>> -return status1;
>> +return status;
>> }
>>
>> /* Release all Stream resources and its context
>
>- omar
--
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 0/4 RFC]OMAP:GPIO: Make GPIO an early init device
* Varadarajan, Charulatha [100216 07:03]:
> > -Original Message-
> > From: Tony Lindgren [mailto:t...@atomide.com]
> > Sent: Monday, February 15, 2010 11:19 PM
> > To: Paul Walmsley
> > Cc: Varadarajan, Charulatha; linux-omap@vger.kernel.org
> > Subject: Re: [PATCH 0/4 RFC]OMAP:GPIO: Make GPIO an early init device
> >
> > * Paul Walmsley [100214 17:38]:
> > > On Fri, 12 Feb 2010, Paul Walmsley wrote:
> > >
> > > > On Fri, 12 Feb 2010, Varadarajan, Charulatha wrote:
> > > >
> > > > > OMAP: Convert GPIO into a early driver
> > > >
> > > > The above patch appears to be missing. Could you please re-send?
> > >
> > > This patch was too big for the mailing list, so it's been posted here:
>
>
> Thanks Paul.
>
> > >
> > > http://www.pwsan.com/omap/patches/gpio/0002-OMAP-GPIO-split-omap1-and-
> > omap2.patch
> >
> > What, make two almost identical copies of the shared code? No way!
> > Instead, please keep the common code under plat-omap:
> >
> > arch/arm/plat-omap/gpio.c
> >
> > Then implement the processor specific functions:
> >
> > arch/arm/mach-omap1/gpio.c
> > arch/arm/mach-omap2/gpio.c
> > arch/arm/mach-omap2/gpio24xx.c
> > arch/arm/mach-omap2/gpio44xx.c
> >
> > Then have a subsys_initcall in processor specific implementation
> > that sets the function pointers in the common code.
> >
> Tony,
>
> The current gpio.c has functions with code similar as mentioned below:
> {
> #ifdef CONFIG_ARCH_OMAP1
> Get the reg offset for OMAP1
> #endif
> #ifdef CONFIG_ARCH_OMAP15XX
> Get the reg offset for OMAP15XX
> #endif
> #ifdef CONFIG_ARCH_OMAP16XX
> Get the reg offset for OMAP16XX
> #endif
> #if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
> Get the reg offset for this OMAP
> #endif
> #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> Get the reg offset for OMAP2&3
> #endif
> #if defined(CONFIG_ARCH_OMAP4)
> Get the reg offset for OMAP4
> #endif
>
> Read/write the register
> }
>
> If function pointers are used in common code (plat-omap/gpio.c), the API's in
> this file would essentially do nothing but invoke these pointers. IMHO this
> is simply adding one unnecessary level of indirection.
> Please correct me if I am missing out something.
For those you can just set the various reg offsets once
during __init based on the omap type and then the function
stays the same.
For example, in arch/arm/mach-omap2/gpio44xx.c you could
have something like the following (completely untested):
static const struct gpio_reg omap4_gpio_reg[] = {
...
};
static const struct gpio_bank omap4_gpio_bank[] = {
...
};
static int omap_gpio_suspend(struct sys_device *dev, pm_message_t mesg)
{
...
}
static int omap_gpio_resume(struct sys_device *dev)
{
...
}
const struct omap_gpio omap4_gpio = {
.regs = omap4_gpio_reg,
.banks = omap4_gpio_bank,
.suspend= omap4_gpio_suspend,
.resume = omap4_gpio_resume,
...
};
...
static int __init omap_gpio_init(void)
{
if (!cpu_is_omap44xx())
return -ENODEV;
return omap_gpio_init(omap4_gpio);
}
arch_initcall(omap44xx_gpio_init);
For some of them, you want to be able to implement the whole
function depending on the omap type that you boot.
We're already doing it like this in most places, the gpio.c code
just needs to be updated for that.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/13] OMAP3/4 clock: split into per-chip family files
* Paul Walmsley [100215 16:56]:
>
> clock34xx_data.c now contains data for the OMAP34xx family, the
> OMAP36xx family, and the OMAP3517 family, so rename it to
> clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the
> chip family-specific clock functions to clock34xx.c, clock36xx.c, or
> clock3517.c, as appropriate. So now "clock3xxx.*" refers to the OMAP3
> superset.
>
> The main goal here is to prepare to compile chip family-specific clock
> functions only for kernel builds that target that chip family. To get to
> that point, we also need to add CONFIG_ARCH_* options for those other
> chip families; that will be done in a future patch, planned for 2.6.35.
Just to comment on the naming, we should call additional cpu options
CONFIG_CPU_OMAP3630 etc instead of CONFIG_ARCH_OMAP to avoid confusion.
I thought about renaming CONFIG_ARCH_OMAP2420 and CONFIG_ARCH_OMAP2430
into CONFIG_CPU_OMAP2420 and CONFIG_CPU_OMAP2430, but as it covers
a bunch of drivers too I've postponed that to 2.6.35.
Any new options should be added as CONFIG_CPU_OMAP3630 and should not
be selectable. Instead, they should get automatically enabled based
on the selected boards in arch/arm/mach-omap2/Kconfig.
Regards,
Tony
> OMAP4 is also affected by this. It duplicated the OMAP3 non-CORE DPLL
> clkops structure. The OMAP4 variant of this clkops structure has been
> removed, and since there was nothing else currently in clock44xx.c, it
> too has been removed -- it can always be added back later when there
> is some content for it. (The OMAP4 clock autogeneration scripts have been
> updated accordingly.)
>
> This second version of the patch fixes some minor errors where the AM35xx
> files were renamed, but the #includes weren't.
>
> Signed-off-by: Paul Walmsley
> Cc: Benoît Cousson
> Cc: Rajendra Nayak
> Cc: Ranjith Lohithakshan
> ---
> arch/arm/mach-omap2/Makefile | 36 ++--
> arch/arm/mach-omap2/clkt34xx_dpll3m2.c |1 +
> arch/arm/mach-omap2/clock.c| 12 +
> arch/arm/mach-omap2/clock.h|2 +
> arch/arm/mach-omap2/clock34xx.c| 260
> +---
> arch/arm/mach-omap2/clock34xx.h| 27 +--
> arch/arm/mach-omap2/clock3517.c| 124 ++
> arch/arm/mach-omap2/clock3517.h| 14 +
> arch/arm/mach-omap2/clock36xx.c| 72 ++
> arch/arm/mach-omap2/clock36xx.h| 13 +
> arch/arm/mach-omap2/clock3xxx.c| 145 +++
> arch/arm/mach-omap2/clock3xxx.h| 21 ++
> .../{clock34xx_data.c => clock3xxx_data.c} | 16 +-
> arch/arm/mach-omap2/clock44xx.c| 19 --
> arch/arm/mach-omap2/clock44xx.h|6 +-
> arch/arm/mach-omap2/clock44xx_data.c | 12 +-
> arch/arm/mach-omap2/io.c |2 +-
> 17 files changed, 450 insertions(+), 332 deletions(-)
> create mode 100644 arch/arm/mach-omap2/clock3517.c
> create mode 100644 arch/arm/mach-omap2/clock3517.h
> create mode 100644 arch/arm/mach-omap2/clock36xx.c
> create mode 100644 arch/arm/mach-omap2/clock36xx.h
> create mode 100644 arch/arm/mach-omap2/clock3xxx.c
> create mode 100644 arch/arm/mach-omap2/clock3xxx.h
> rename arch/arm/mach-omap2/{clock34xx_data.c => clock3xxx_data.c} (99%)
> delete mode 100644 arch/arm/mach-omap2/clock44xx.c
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 10e6c6e..03058ad 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -7,22 +7,14 @@ obj-y := id.o io.o control.o mux.o devices.o serial.o
> gpmc.o timer-gp.o
>
> omap-2-3-common = irq.o sdrc.o omap_hwmod.o \
> omap_hwmod_common_data.o
> -omap-3-4-common = dpll3xxx.o
> prcm-common = prcm.o powerdomain.o
> clock-common = clock.o clock_common_data.o \
> clockdomain.o clkt_dpll.o \
> clkt_clksel.o
> -clock-omap2xxx = clkt2xxx_dpllcore.o \
> - clkt2xxx_virt_prcm_set.o \
> - clkt2xxx_apll.o clkt2xxx_osc.o \
> - clkt2xxx_sys.o
> -clock-omap3xxx = clkt34xx_dpll3m2.o
> -
> -obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common)
> $(clock-common) \
> - $(clock-omap2xxx)
> -obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common)
> $(clock-common) \
> - $(omap-3-4-common) $(clock-omap3xxx)
> -obj-$(CONFIG_ARCH_OMAP4) += $(omap-3-4-common) $(prcm-common) $(clock-common)
> +
> +obj-$(CONFIG_ARCH_OMAP2) += $
Re: [PATCH 2/2] DSPBRIDGE: New reserved memory accounting framework
On Tue, Feb 16, 2010 at 3:20 PM, Ameya Palande wrote:
> DSP_RSV_OBJECT is introduced to track reserved memory accounting information.
> This will allow us to do proper cleanup for memory reserved using
> PROC_ReserveMemory().
>
> Signed-off-by: Ameya Palande
> ---
> arch/arm/plat-omap/include/dspbridge/drv.h | 13 ++
> arch/arm/plat-omap/include/dspbridge/proc.h | 5 +-
> drivers/dsp/bridge/pmgr/dmm.c | 3 +-
> drivers/dsp/bridge/pmgr/wcd.c | 7 ++-
> drivers/dsp/bridge/rmgr/drv.c | 27 +---
> drivers/dsp/bridge/rmgr/drv_interface.c | 7 ++-
> drivers/dsp/bridge/rmgr/node.c | 5 +-
> drivers/dsp/bridge/rmgr/proc.c | 58 +-
> 8 files changed, 97 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h
> b/arch/arm/plat-omap/include/dspbridge/drv.h
> index 3069e74..6e8187d 100644
> --- a/arch/arm/plat-omap/include/dspbridge/drv.h
> +++ b/arch/arm/plat-omap/include/dspbridge/drv.h
> @@ -101,6 +101,15 @@ struct DMM_MAP_OBJECT {
> struct DMM_MAP_OBJECT *next;
> } ;
>
> +/*
> + * New structure (member of process context) used for accounting of DMM
> + * reserved memory information
> + */
> +struct DMM_RSV_OBJECT {
> + struct list_head link;
> + u32 dsp_reserved_addr;
> +};
> +
> /* New structure (member of process context) abstracts DMM resource info */
> struct DSPHEAP_RES_OBJECT {
> s32 heapAllocated; /* DMM status */
> @@ -141,6 +150,10 @@ struct PROCESS_CONTEXT{
> /* DMM mapped memory resources */
> struct DMM_MAP_OBJECT *dmm_map_list;
>
> + /* DMM reserved memory resources */
> + struct list_head dmm_rsv_list;
> + spinlock_t dmm_rsv_list_lock;
> +
Why rsv requires a spinlock, but not map?
I guess it would be needed if somehow PROC_UnReserveMemory() was
called by user-space at the same time than bridge_close, but is that
really possible? If it is, then the same danger is present with
PROC_UnMap() unless I'm missing something.
> /* DSP Heap resources */
> struct DSPHEAP_RES_OBJECT *pDSPHEAPList;
>
> diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h
> b/arch/arm/plat-omap/include/dspbridge/proc.h
> index 8dbdaac..558c053 100644
> --- a/arch/arm/plat-omap/include/dspbridge/proc.h
> +++ b/arch/arm/plat-omap/include/dspbridge/proc.h
> @@ -560,7 +560,7 @@
> * Details:
> */
> extern DSP_STATUS PROC_ReserveMemory(DSP_HPROCESSOR hProcessor,
> - u32 ulSize, void **ppRsvAddr);
> + u32 ulSize, void **ppRsvAddr, struct PROCESS_CONTEXT
> *pr_ctxt);
>
> /*
> * PROC_UnMap
> @@ -604,6 +604,7 @@
> * Details:
> */
> extern DSP_STATUS PROC_UnReserveMemory(DSP_HPROCESSOR hProcessor,
> - void *pRsvAddr);
> + void *pRsvAddr, struct PROCESS_CONTEXT *pr_ctxt,
> + int cleanup);
>
> #endif /* PROC_ */
> diff --git a/drivers/dsp/bridge/pmgr/dmm.c b/drivers/dsp/bridge/pmgr/dmm.c
> index d5a7275..72aee60 100644
> --- a/drivers/dsp/bridge/pmgr/dmm.c
> +++ b/drivers/dsp/bridge/pmgr/dmm.c
> @@ -386,9 +386,10 @@ DSP_STATUS DMM_ReserveMemory(struct DMM_OBJECT *hDmmMgr,
> u32 size,
> node->MappedSize = 0;
> /* Return the chunk's starting address */
> *pRsvAddr = rsvAddr;
> - } else
> + } else {
> /*dSP chunk of given size is not available */
> status = DSP_EMEMORY;
> + }
>
> SYNC_LeaveCS(pDmmObj->hDmmLock);
> GT_3trace(DMM_debugMask, GT_4CLASS,
> diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
> index beea23b..747d069 100644
> --- a/drivers/dsp/bridge/pmgr/wcd.c
> +++ b/drivers/dsp/bridge/pmgr/wcd.c
> @@ -1054,12 +1054,13 @@ u32 PROCWRAP_ReserveMemory(union Trapped_Args *args,
> void *pr_ctxt)
>
> GT_0trace(WCD_debugMask, GT_ENTER, "PROCWRAP_ReserveMemory:
> entered\n");
> status = PROC_ReserveMemory(args->ARGS_PROC_RSVMEM.hProcessor,
> - args->ARGS_PROC_RSVMEM.ulSize, &pRsvAddr);
> + args->ARGS_PROC_RSVMEM.ulSize, &pRsvAddr,
> + pr_ctxt);
> if (DSP_SUCCEEDED(status)) {
> if (put_user(pRsvAddr, args->ARGS_PROC_RSVMEM.ppRsvAddr)) {
> status = DSP_EINVALIDARG;
> PROC_UnReserveMemory(args->ARGS_PROC_RSVMEM.hProcessor,
> - pRsvAddr);
> + pRsvAddr, pr_ctxt, 1);
> }
> }
> return status;
> @@ -1100,7 +1101,7 @@ u32 PROCWRAP_UnReserveMemory(union Trapped_Args *args,
> void *pr_ctxt)
> GT_0trace(WCD_debugMask, GT_ENTER,
> "PROCWRAP_UnReserveMemory:
Re: [PATCH 0/24] omap4 for 2.6.34
Hi, * Shilimkar, Santosh [100216 07:33]: > Tony, > Here are some patches towards upcoming 34 merge window. They are generated > against > linux-omap master as you suggested. > > I am also copying Ben, Samuel, Liam, Paul and Kevin since some of the changes > are in mfd, regulator, i2c and clocks. Thanks. Can you please split this into several smaller sets? 1. Core omap changes done against linux-omap master branch Send to linux-omap list with linux-arm-kernel Cc'd. 2. Clock framework dummy_ck changes done against linux-omap master branch. This should leave out most of the driver changes in your series. Send to linux-omap list with linux-arm-kernel Cc'd. 3. I2C changes against done against 2.6.33-rc8 + "Add support for 16-bit registers" Send to Ben and i2c list with linux-omap list Cc'd. 4. MFD changes done against 2.6.33-rc8 Send to Samuel with linux-omap list Cc'd. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/24] omap4: multi-omap: Allow build to work
* Santosh Shilimkar [100216 07:55]: > The musb support is enable to omap3 platforms. For omap4 only board > support is available and the driver still isn't supported. > Because of this build with omap3_defconfig used for multi-omap > doesn't work on omap4430 sdp. > > This patch hacks the musb probe to keep the multi-omap build > working on omap4430 sdp > > Signed-off-by: Santosh Shilimkar > --- > drivers/usb/musb/musb_core.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c > index bcce8e8..13b1c4a 100644 > --- a/drivers/usb/musb/musb_core.c > +++ b/drivers/usb/musb/musb_core.c > @@ -2124,6 +2124,10 @@ static int __init musb_probe(struct platform_device > *pdev) > struct resource *iomem; > void __iomem*base; > > + /* FIXME: multi-omap build to work on omap4 */ > + if (cpu_is_omap44xx()) > + return 0; > + > iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > if (!iomem || irq == 0) > return -ENODEV; Should the comment here be "FIXME: allow multi-omap to boot until musb is updated for omap4" instead? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/24] omap4: Add i2c support on omap4 platform
* Santosh Shilimkar [100216 07:55]:
> This patch is rebased version of earlier post to add I2C
> driver support to OMAP4 platform. On OMAP4, all
> I2C register address offsets are changed from OMAP1/2/3 I2C.
> In order to not have #ifdef's at various places in code,
> as well as to support multi-OMAP build, an array is created
> to hold the register addresses with it's offset.
>
> This patch was submitted, reviewed and acked on mailing list
> already. For more details refer below link
> http://www.mail-archive.com/linux-...@vger.kernel.org/msg02281.html
>
> This version updated on top of 16 bit support added as part of
> the commit "8bb209278e555a626f9637e844fe4c1b90e849f6"
>
> Signed-off-by: Syed Rafiuddin
> Signed-off-by: Santosh Shilimkar
> Acked-by: Kevin Hilman
> CC: Tony Lindgren
> CC: Ben Dooks
> ---
> arch/arm/plat-omap/i2c.c | 17 -
> drivers/i2c/busses/i2c-omap.c | 148
> -
> 2 files changed, 131 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
> index 96d2781..f18d757 100644
> --- a/arch/arm/plat-omap/i2c.c
> +++ b/arch/arm/plat-omap/i2c.c
> @@ -53,9 +53,15 @@ static struct resource i2c_resources[][2] = {
> #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE2, INT_24XX_I2C2_IRQ) },
> #endif
> +#if defined(CONFIG_ARCH_OMAP4)
> + { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE2, INT_44XX_I2C2_IRQ) },
> +#endif
> #if defined(CONFIG_ARCH_OMAP3)
> { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE3, INT_34XX_I2C3_IRQ) },
> #endif
> +#if defined(CONFIG_ARCH_OMAP4)
> + { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE3, INT_44XX_I2C3_IRQ) },
> +#endif
> };
This is OK, but..
> #define I2C_DEV_BUILDER(bus_id, res, data) \
> @@ -72,10 +78,11 @@ static struct resource i2c_resources[][2] = {
> static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
> static struct platform_device omap_i2c_devices[] = {
> I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_rate[0]),
> -#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> +#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
> + defined(CONFIG_ARCH_OMAP4)
> I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
> #endif
> -#if defined(CONFIG_ARCH_OMAP3)
> +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
> #endif
> };
.. the ifdefs above can be simplified to ifdef CONFIG_ARCH_OMAP2PLUS.
That is, with the patches already queued into omap for-next.
> @@ -370,7 +434,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> internal_clk = 9600;
> else
> internal_clk = 4000;
> - fclk_rate = clk_get_rate(dev->fclk) / 1000;
> + /* FIXME: Remove this once clock framework is available*/
> + if (dev->rev >= OMAP_I2C_REV_ON_4430)
> + fclk_rate = 96000;
> + else
> + fclk_rate = clk_get_rate(dev->fclk) / 1000;
>
> /* Compute prescaler divisor */
> psc = fclk_rate / internal_clk;
Sounds like this part should no longer be needed?
> *dev->buf++ = w;
> dev->buf_len--;
> - /* Data reg from 2430 is 8 bit wide */
> + /* Data reg in 2430, omap3 and
> + * omap4 is 8 bit wide
> + */
> if (!cpu_is_omap2430() &&
> - !cpu_is_omap34xx()) {
> + !cpu_is_omap34xx() &&
> + !cpu_is_omap44xx()) {
> if (dev->buf_len) {
> *dev->buf++ = w >> 8;
> dev->buf_len--;
How about change this to if (cpu_class_is_omap1() || cpu_is_omap2420())?
That way it does not need to be patched for new omaps.
> @@ -786,9 +857,12 @@ complete:
> if (dev->buf_len) {
> w = *dev->buf++;
> dev->buf_len--;
> - /* Data reg from 2430 is 8 bit wide */
> + /* Data reg in 2430, omap3 and
> + * omap4 is 8 bit wide
> + */
> if (!cpu_is_omap2430() &&
> - !cpu_is_omap34xx()) {
> + !cpu_is_omap34xx() &&
> +
Re: [PATCH 14/24] omap4: Enable WDT and McBSP support
* Santosh Shilimkar [100216 07:55]: > This patch enables watchdog timer and McBSP support on omap4430 > sdp platform. > Additinaly the uart3 made as default console in the omap_4430sdp_defconfig This probably cannot be applied until the dummy_ck handling is added for omap4. Regards, Tony > Signed-off-by: Balaji T K > Signed-off-by: Santosh Shilimkar > --- > arch/arm/configs/omap_4430sdp_defconfig |7 --- > drivers/watchdog/Kconfig|6 +++--- > 2 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/configs/omap_4430sdp_defconfig > b/arch/arm/configs/omap_4430sdp_defconfig > index 3de640a..7ac3fbf 100644 > --- a/arch/arm/configs/omap_4430sdp_defconfig > +++ b/arch/arm/configs/omap_4430sdp_defconfig > @@ -199,7 +199,7 @@ CONFIG_ARCH_OMAP4=y > # > # CONFIG_OMAP_RESET_CLOCKS is not set > # CONFIG_OMAP_MUX is not set > -# CONFIG_OMAP_MCBSP is not set > +CONFIG_OMAP_MCBSP=y > # CONFIG_OMAP_MBOX_FWK is not set > # CONFIG_OMAP_MPU_TIMER is not set > CONFIG_OMAP_32K_TIMER=y > @@ -304,7 +304,7 @@ CONFIG_ALIGNMENT_TRAP=y > # > CONFIG_ZBOOT_ROM_TEXT=0x0 > CONFIG_ZBOOT_ROM_BSS=0x0 > -CONFIG_CMDLINE="root=/dev/ram0 rw mem=128M console=ttyS0,115200n8 > initrd=0x8160,20M ramdisk_size=20480" > +CONFIG_CMDLINE="root=/dev/ram0 rw mem=128M console=ttyS2,115200n8 > initrd=0x8160,20M ramdisk_size=20480" > # CONFIG_XIP_KERNEL is not set > # CONFIG_KEXEC is not set > > @@ -488,7 +488,8 @@ CONFIG_GPIOLIB=y > # CONFIG_POWER_SUPPLY is not set > # CONFIG_HWMON is not set > # CONFIG_THERMAL is not set > -# CONFIG_WATCHDOG is not set > +CONFIG_WATCHDOG=y > +CONFIG_OMAP_WATCHDOG=y > CONFIG_SSB_POSSIBLE=y > > # > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index 3da3f48..1185f05 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -194,10 +194,10 @@ config EP93XX_WATCHDOG > > config OMAP_WATCHDOG > tristate "OMAP Watchdog" > - depends on ARCH_OMAP16XX || ARCH_OMAP2 || ARCH_OMAP3 > + depends on ARCH_OMAP16XX || ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 > help > - Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430 watchdog. Say 'Y' > - here to enable the OMAP1610/OMAP1710/OMAP2420/OMAP3430 watchdog timer. > + Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog. > Say 'Y' > + here to enable the OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 > watchdog timer. > > config PNX4008_WATCHDOG > tristate "PNX4008 Watchdog" > -- > 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 13/24] omap4: clocks: Remove clock hacks from timer-gp.c
* Santosh Shilimkar [100216 07:55]:
> Now the omap4 clock framework is mainline and clk_get_rate()
> is functional. Hence reomve the hardcoded clock hacks.
Should we send this as a fix for 2.6.33, or does this depend
on other patches not yet in 2.6.33?
Regards,
Tony
> This patch also fixes
> Division by zero in kernel.
> Backtrace:
> [] (dump_backtrace+0x0/0x110) from []
> (dump_stack+0x18/0x1c)
> r7:6093 r6:c0641050 r5:c0223e78 r4:c02126b4
> [] (dump_stack+0x0/0x1c) from [] (__div0+0x18/0x20)
> [] (__div0+0x0/0x20) from [] (Ldiv0+0x8/0x10)
> [] (omap_dm_timer_stop+0x0/0xb0) from []
> (omap2_gp_timer_set_mode+0x1c/0x68)
> r5:c0223e78 r4:
> [] (omap2_gp_timer_set_mode+0x0/0x68) from []
> (clockevents_set_mode+0x30/0x64)
> r5:c020cae0 r4:
> [] (clockevents_set_mode+0x0/0x64) from []
> (clockevents_exchange_device+0x30/0x9c)
> r5:c020cae0 r4:c02146e0
> [] (clockevents_exchange_device+0x0/0x9c) from []
> (tick_notify+0x17c/0x404)
> r7: r6:c0641050 r5: r4:c020cae0
> [] (tick_notify+0x0/0x404) from []
> (notifier_call_chain+0x34/0x78)
> [] (notifier_call_chain+0x0/0x78) from []
> (__raw_notifier_call_chain+0x1c/0x24)
> [] (__raw_notifier_call_chain+0x0/0x24) from []
> (raw_notifier_call_chain+0x20/0x28)
> [] (raw_notifier_call_chain+0x0/0x28) from []
> (clockevents_do_notify+0x1c/0x24)
> [] (clockevents_do_notify+0x0/0x24) from []
> (clockevents_register_device+0x98/0xd0)
> [] (clockevents_register_device+0x0/0xd0) from []
> (percpu_timer_setup+0x80/0x9c)
> r7: r6:0002 r5:0002 r4:0003
> [] (percpu_timer_setup+0x0/0x9c) from []
> (smp_prepare_cpus+0xb0/0xe8)
> [] (smp_prepare_cpus+0x0/0xe8) from []
> (kernel_init+0x5c/0x1fc)
> r7: r6: r5: r4:c001b8a4
> [] (kernel_init+0x0/0x1fc) from [] (do_exit+0x0/0x604)
> r7: r6: r5: r4:
>
> Signed-off-by: Santosh Shilimkar
> ---
> arch/arm/mach-omap2/timer-gp.c |5 -
> 1 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
> index cd04dea..74fbed8 100644
> --- a/arch/arm/mach-omap2/timer-gp.c
> +++ b/arch/arm/mach-omap2/timer-gp.c
> @@ -85,8 +85,6 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
> mode,
> case CLOCK_EVT_MODE_PERIODIC:
> period = clk_get_rate(omap_dm_timer_get_fclk(gptimer)) / HZ;
> period -= 1;
> - if (cpu_is_omap44xx())
> - period = 0xff; /* FIXME: */
> omap_dm_timer_set_load_start(gptimer, 1, 0x - period);
> break;
> case CLOCK_EVT_MODE_ONESHOT:
> @@ -150,9 +148,6 @@ static void __init omap2_gp_clockevent_init(void)
>"timer-gp: omap_dm_timer_set_source() failed\n");
>
> tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer));
> - if (cpu_is_omap44xx())
> - /* Assuming 32kHz clk is driving GPT1 */
> - tick_rate = 32768; /* FIXME: */
>
> pr_info("OMAP clockevent source: GPTIMER%d at %u Hz\n",
> gptimer_id, tick_rate);
> --
> 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 08/24] omap4: clocks: Make Uart driver's clock calls OMAP4 compatible
* Santosh Shilimkar [100216 07:55]: > From: Abhijit Pagare > > The uart driver has been adapted for the OMAP4 way of clock calls. > > Signed-off-by: Abhijit Pagare > --- > arch/arm/mach-omap2/serial.c | 24 > 1 files changed, 16 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c > index b79bc89..97859b0 100644 > --- a/arch/arm/mach-omap2/serial.c > +++ b/arch/arm/mach-omap2/serial.c > @@ -257,7 +257,8 @@ static inline void omap_uart_enable_clocks(struct > omap_uart_state *uart) > return; > > clk_enable(uart->ick); > - clk_enable(uart->fck); > + if (!cpu_is_omap44xx()) > + clk_enable(uart->fck); > uart->clocked = 1; > omap_uart_restore_context(uart); > } > @@ -272,7 +273,8 @@ static inline void omap_uart_disable_clocks(struct > omap_uart_state *uart) > omap_uart_save_context(uart); > uart->clocked = 0; > clk_disable(uart->ick); > - clk_disable(uart->fck); > + if (!cpu_is_omap44xx()) > + clk_disable(uart->fck); > } As discussed outside the lists, the fck handling for omap4 should be done with dummy_ck the same way as we're already doing for omap1. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] DSPBRIDGE: Rename DMM_RES_OBJECT to DMM_MAP_OBJECT
On Tue, Feb 16, 2010 at 3:20 PM, Ameya Palande wrote: > In its current state DMM_RES_OBJECT is not correctly tracking reserve and > unreserve but only map and unmap. So lets rename it to DMM_MAP_OBJECT to > clarify what it is really doing! > > In addition to this, this patch also does some trivial code cleanup. > > Signed-off-by: Ameya Palande Reviewed-by: Felipe Contreras -- Felipe Contreras -- 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: omap3evm: Doesn't boot at 4fa42e46
* Premi, Sanjeev [100216 01:35]:
> > -Original Message-
> > From: Lohithakshan, Ranjith
> > Sent: Tuesday, February 16, 2010 2:22 PM
> > To: Premi, Sanjeev
> > Cc: Tony Lindgren; linux-omap@vger.kernel.org; Lohithakshan, Ranjith
> > Subject: Re: omap3evm: Doesn't boot at 4fa42e46
> >
> > This one line change seem to fix the issue on my end
> >
> > --- a/arch/arm/mach-omap2/mux.c
> > +++ b/arch/arm/mach-omap2/mux.c
> > @@ -969,7 +969,7 @@ static void __init omap_mux_init_list(struct
> > omap_mux *super
> > }
> > #endif
> >
> > -#if defined(CONFIG_OMAP_MUX) && defined(CONFIG_DEBUG_FS)
> > +#ifdef CONFIG_OMAP_MUX
> > if (!superset->muxnames || !superset->muxnames[0]) {
> > superset++;
> > continue;
> >
> > Not sure why DebugFS need to be defined for the muxname
> > check. omap3evm
> > and zoom2/3 dont have DebugFS enabled by default in defconfig and that
> > could explain why these platforms not booting up.
Hmm sounds like that's a bug there. The muxnames are available only during
__init, and optimized out if CONFIG_OMAP_MUX is not set. Initially the
muxnames were there only if CONFIG_DEBUG_FS was set.
> >
> > A formal patch will follow once I get more confirmations that this
> > change is working.
Please send a formal patch ASAP so we can get it into 2.6.33.
> The git-bisect brings me here:
>
> premi # g-log-10 78737ae
> 78737ae : omap: Fix arch/arm/mach-omap2/mux.c: Off by one error
> 9ecef43 : omap: Fix 3630 mux errors
> 8d08436 : OMAP2/3: GPMC: ensure valid clock pointer
> 74005a2 : OMAP2/3: IRQ: ensure valid base address
>
> Kernel boots fine at "8d08436". There was earlier a discussion on "9ecef43"
> but
> it 'seems' to be specific for 3630 only.
>
> But the condition you pointed is added at "9ecef43". So, this IS the problem.
>
> I am also trying to check if "78737ae" could also lead to a potential error.
The only concernd there AFAIK is that if mode0 names for some yet unknown
mux modes are longer than OMAP_MUX_DEFNAME_LEN.
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
OMAP Audio
I need to connect the OMAP (3530) to a 24bit CODEC. So far my attempts at getting this to go have not gone well. Then I ran across this comment in sound/soc/omap/omap-pcm.c: /* * Note: Regardless of interface data formats supported by OMAP McBSP * or EAC blocks, internal representation is always fixed 16-bit/sample */ Does this mean that this setup is just not supported? even though the hardware can handle it? Thanks for any pointers or ideas on how to get this going. -- 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: DSPBRIDGE: Reclaim all pending buffer on resource cleanup
Hi,
On 2/8/2010 4:20 PM, Guzman Lugo, Fernando wrote:
From 727c83cd8b7e4aca51b214412eaa1b95cde6e4ea Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo
Date: Tue, 2 Feb 2010 20:38:10 -0600
Subject: [PATCH] DSPBRIDGE: Reclaim all pending buffer on resource cleanup
Before in case of pending buffer while we try to close
a stream, it was doing only one reclaim, in the case there
were more pending buffer the second STRM_Close would also
fail, now all the pending buffers are reclaim.
Signed-off-by: Fernando Guzman Lugo
---
Shouldn't this be like?
Patch 1: Fix
Patch 2: code enhancement
that said, isn't this missing a STRM_Close? (look below)
drivers/dsp/bridge/rmgr/drv.c | 37 -
1 files changed, 16 insertions(+), 21 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index edd8e97..660f375 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -458,40 +458,35 @@ static DSP_STATUS DRV_ProcFreeSTRMRes(HANDLE hPCtxt)
{
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
DSP_STATUS status = DSP_SOK;
- DSP_STATUS status1 = DSP_SOK;
u8 **apBuffer = NULL;
- struct STRM_RES_OBJECT *pSTRMList = NULL;
struct STRM_RES_OBJECT *pSTRMRes = NULL;
+ struct STRM_INFO strm_info;
+ struct DSP_STREAMINFO user;
u8 *pBufPtr;
u32 ulBytes;
u32 dwArg;
s32 ulBufSize;
- pSTRMList = pCtxt->pSTRMList;
- while (pSTRMList != NULL) {
- pSTRMRes = pSTRMList;
- pSTRMList = pSTRMList->next;
- if (pSTRMRes->uNumBufs != 0) {
- apBuffer = MEM_Alloc((pSTRMRes->uNumBufs *
- sizeof(u8 *)), MEM_NONPAGED);
+ pSTRMRes = pCtxt->pSTRMList;
+ while (pSTRMRes) {
+ if (pSTRMRes->uNumBufs) {
+ apBuffer = MEM_Alloc(pSTRMRes->uNumBufs *
+ sizeof(u8 *), MEM_NONPAGED);
+ if (!apBuffer)
+ return DSP_EMEMORY;
status = STRM_FreeBuffer(pSTRMRes->hStream, apBuffer,
pSTRMRes->uNumBufs, pCtxt);
MEM_Free(apBuffer);
}
- status = STRM_Close(pSTRMRes->hStream, pCtxt);
- if (DSP_FAILED(status)) {
- if (status == DSP_EPENDING) {
- status = STRM_Reclaim(pSTRMRes->hStream,
- &pBufPtr,&ulBytes,
-(u32 *)&ulBufSize,&dwArg);
- if (DSP_SUCCEEDED(status))
- status = STRM_Close(pSTRMRes->hStream,
- pCtxt);
+ strm_info.pUser =&user;
+ user.uNumberBufsInStream = 0;
+ STRM_GetInfo(pSTRMRes->hStream,&strm_info, sizeof(strm_info));
+ while (strm_info.pUser->uNumberBufsInStream--)
+ STRM_Reclaim(pSTRMRes->hStream,&pBufPtr,&ulBytes,
+(u32 *)&ulBufSize,&dwArg);
Here.
- }
- }
}
- return status1;
+ return status;
}
/* Release all Stream resources and its context
- omar
--
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 12/19] OMAP3 clock: Remove FreqSel for 3630
Hello Sergei,
On Tue, 16 Feb 2010, Sergei Shtylyov wrote:
> Paul Walmsley wrote:
>
> > From: Vishwanath BS
> >
> > diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
> > index 2b559fc..84be81c 100644
> > --- a/arch/arm/mach-omap2/dpll3xxx.c
> > +++ b/arch/arm/mach-omap2/dpll3xxx.c
> > @@ -243,8 +243,11 @@ static int omap3_noncore_dpll_program(struct clk *clk,
> > u16 m, u8 n, u16 freqsel)
> > /* 3430 ES2 TRM: 4.7.6.9 DPLL Programming Sequence */
> > _omap3_noncore_dpll_bypass(clk);
> > - /* Set jitter correction */
> > - if (!cpu_is_omap44xx()) {
> > + /*
> > +* Set jitter correction. No jitter correction for OMAP4 and 3630
> > +* since freqsel is field is no longer present
> >
>
> I can't parse that comment. I guess first "is" is not needed. :-)
Thanks Sergei; fixed in the for_2.6.34_dev branch; revised branch below.
- Paul
From: Vishwanath BS
Date: Fri, 12 Feb 2010 14:25:04 -0700
Subject: [PATCH] OMAP3 clock: Remove FreqSel for 3630
DPLL_FREQSEL field in CLKEN_PLL register is no longer valid for
OMAP3630. So remove references to that.
Signed-off-by: Vishwanath BS
Cc: Sergei Shtylyov
[p...@pwsan.com: added comment fix from Sergei Shtylyov]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/dpll3xxx.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 2b559fc..68268cd 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -243,8 +243,11 @@ static int omap3_noncore_dpll_program(struct clk *clk, u16
m, u8 n, u16 freqsel)
/* 3430 ES2 TRM: 4.7.6.9 DPLL Programming Sequence */
_omap3_noncore_dpll_bypass(clk);
- /* Set jitter correction */
- if (!cpu_is_omap44xx()) {
+ /*
+* Set jitter correction. No jitter correction for OMAP4 and 3630
+* since freqsel field is no longer present
+*/
+ if (!cpu_is_omap44xx() && !cpu_is_omap3630()) {
v = __raw_readl(dd->control_reg);
v &= ~dd->freqsel_mask;
v |= freqsel << __ffs(dd->freqsel_mask);
@@ -387,8 +390,8 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
if (dd->last_rounded_rate == 0)
return -EINVAL;
- /* No freqsel on OMAP4 */
- if (!cpu_is_omap44xx()) {
+ /* No freqsel on OMAP4 and OMAP3630 */
+ if (!cpu_is_omap44xx() && !cpu_is_omap3630()) {
freqsel = _omap3_dpll_compute_freqsel(clk,
dd->last_rounded_n);
if (!freqsel)
--
1.6.6.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] DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes
Hi,
On Tue, Feb 16, 2010 at 2:38 PM, Ameya Palande wrote:
> Hi Felipe,
>
> On Mon, 2010-02-15 at 16:59 +0100, Contreras Felipe (Nokia-D/Helsinki)
> wrote:
>> On Mon, Feb 15, 2010 at 04:36:31PM +0100, Ameya Palande wrote:
>> > --- a/drivers/dsp/bridge/rmgr/drv.c
>> > +++ b/drivers/dsp/bridge/rmgr/drv.c
>> > @@ -273,11 +273,14 @@ DSP_STATUS DRV_ProcFreeDMMRes(HANDLE hPCtxt)
>> > pDMMList = pDMMList->next;
>> > if (pDMMRes->dmmAllocated) {
>> > status = PROC_UnMap(pDMMRes->hProcessor,
>> > - (void *)pDMMRes->ulDSPResAddr, pCtxt);
>> > + (void *)pDMMRes->ulDSPAddr, pCtxt);
>> > + /*
>> > + * PROC_UnMap has freed pDMMRes pointer, so don't
>> > access
>> > + * it now
>> > + */
>>
>> I don't see the need for this comment on the code.
>
> In above code segment, just by looking at PROC_Unmap() it is not
> apparent that it will deallocate "pDMMRes" thats why that comment is
> present there! I guess this whole memory corruption could have been
> easily avoided by presence of that comment ;)
Then the comment should be on PROC_Unmap() I guess.
--
Felipe Contreras
--
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 24/24] omap4: multi-omap: Allow build to work
Anand, > -Original Message- > From: Gadiyar, Anand > Sent: Tuesday, February 16, 2010 9:25 PM > To: Shilimkar, Santosh; t...@atomide.com > Cc: linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com; > l...@slimlogic.co.uk; > p...@pwsan.com > Subject: RE: [PATCH] omap4: multi-omap: Allow build to work > > Shilimkar, Santosh wrote: > > The musb support is enable to omap3 platforms. For omap4 only board > > support is available and the driver still isn't supported. > > Because of this build with omap3_defconfig used for multi-omap > > doesn't work on omap4430 sdp. > > > > This patch hacks the musb probe to keep the multi-omap build > > working on omap4430 sdp > > > > Signed-off-by: Santosh Shilimkar > > --- > > drivers/usb/musb/musb_core.c |4 > > 1 files changed, 4 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/usb/musb/musb_core.c > > b/drivers/usb/musb/musb_core.c > > index bcce8e8..13b1c4a 100644 > > --- a/drivers/usb/musb/musb_core.c > > +++ b/drivers/usb/musb/musb_core.c > > @@ -2124,6 +2124,10 @@ static int __init musb_probe(struct > > platform_device *pdev) > > struct resource *iomem; > > void __iomem*base; > > > > + /* FIXME: multi-omap build to work on omap4 */ > > + if (cpu_is_omap44xx()) > > + return 0; > > + > > NAK. I'd prefer that we fix the driver issue correctly. > > I would have expected the driver to at least load on OMAP4 > even if it does not work. Could you please describe the > failure? > The probe fails because the register bases aren't mapped for omap4. This is because Tony has lined-up musb board support for omap4 but corresponding usb driver patches are not yet lined up. > Also, this will need to go through linux-usb. -- 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 15/24] omap4: clocks: Convert i2c clocks data to fclks
In OMAP4 I2C module has only fclk control and iclks are controlled
through hardware.(The OMAP4 clock tree autogeneration script has
been updated accordingly.)
CC:Paul Walmsley
CC:Benoit Cousson
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/clock44xx_data.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 86af31d..a69e8a0 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2665,10 +2665,10 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "gptimer9_ck", &gptimer9_ck,
CK_443X),
CLK("omap2_hdq.0", "ick", &hdq1w_ck,
CK_443X),
CLK(NULL, "hsi_ck", &hsi_ck,
CK_443X),
- CLK("i2c_omap.1", "ick", &i2c1_ck,
CK_443X),
- CLK("i2c_omap.2", "ick", &i2c2_ck,
CK_443X),
- CLK("i2c_omap.3", "ick", &i2c3_ck,
CK_443X),
- CLK("i2c_omap.4", "ick", &i2c4_ck,
CK_443X),
+ CLK("i2c_omap.1", "fck", &i2c1_ck,
CK_443X),
+ CLK("i2c_omap.2", "fck", &i2c2_ck,
CK_443X),
+ CLK("i2c_omap.3", "fck", &i2c3_ck,
CK_443X),
+ CLK("i2c_omap.4", "fck", &i2c4_ck,
CK_443X),
CLK(NULL, "iss_ck", &iss_ck,
CK_443X),
CLK(NULL, "ivahd_ck", &ivahd_ck,
CK_443X),
CLK(NULL, "keyboard_ck", &keyboard_ck,
CK_443X),
--
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 02/24] omap2/3/4: ioremap omap_globals module
This is a clean-up patch towards dynamic allocation of IO space
instead of using harcoded macros to calculate virtual addresses.
Also update the sdrc, prcm, tap and control module to
allocate iospace dynamically
As per Tony's suggestion V2 version drops tap changes
becasue ioremap uses cpu_is_omap2420() and cpu_is_omap2430(),
so we can't use that for setting tap_base. Hence ioremap()
won't work for tap until omap2_check_revision() is done
Signed-off-by: Santosh Shilimkar
CC: Kevin Hilman
CC: Tony Lindgren
---
arch/arm/mach-omap2/control.c|6 -
arch/arm/mach-omap2/prcm.c | 16 ++--
arch/arm/mach-omap2/sdrc.c | 11 +++-
arch/arm/plat-omap/common.c | 38 +++---
arch/arm/plat-omap/include/plat/common.h | 12
5 files changed, 52 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index cdd1f35..43f8a33 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -140,7 +140,11 @@ static struct omap3_control_regs control_context;
void __init omap2_set_globals_control(struct omap_globals *omap2_globals)
{
- omap2_ctrl_base = omap2_globals->ctrl;
+ /* Static mapping, never released */
+ if (omap2_globals->ctrl) {
+ omap2_ctrl_base = ioremap(omap2_globals->ctrl, SZ_4K);
+ WARN_ON(!omap2_ctrl_base);
+ }
}
void __iomem *omap_ctrl_base_get(void)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index e8e121a..338d5f6 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -279,9 +279,19 @@ int omap2_cm_wait_idlest(void __iomem *reg, u32 mask,
const char *name)
void __init omap2_set_globals_prcm(struct omap_globals *omap2_globals)
{
- prm_base = omap2_globals->prm;
- cm_base = omap2_globals->cm;
- cm2_base = omap2_globals->cm2;
+ /* Static mapping, never released */
+ if (omap2_globals->prm) {
+ prm_base = ioremap(omap2_globals->prm, SZ_8K);
+ WARN_ON(!prm_base);
+ }
+ if (omap2_globals->cm) {
+ cm_base = ioremap(omap2_globals->cm, SZ_8K);
+ WARN_ON(!cm_base);
+ }
+ if (omap2_globals->cm2) {
+ cm2_base = ioremap(omap2_globals->cm2, SZ_8K);
+ WARN_ON(!cm2_base);
+ }
}
#ifdef CONFIG_ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index cbfbd14..4c65f56 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -119,8 +119,15 @@ int omap2_sdrc_get_params(unsigned long r,
void __init omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
{
- omap2_sdrc_base = omap2_globals->sdrc;
- omap2_sms_base = omap2_globals->sms;
+ /* Static mapping, never released */
+ if (omap2_globals->sdrc) {
+ omap2_sdrc_base = ioremap(omap2_globals->sdrc, SZ_64K);
+ WARN_ON(!omap2_sdrc_base);
+ }
+ if (omap2_globals->sms) {
+ omap2_sms_base = ioremap(omap2_globals->sms, SZ_64K);
+ WARN_ON(!omap2_sms_base);
+ }
}
/**
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 4f29e8c..ee9499e 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -256,11 +256,11 @@ static void __init __omap2_set_globals(struct
omap_globals *omap2_globals)
static struct omap_globals omap242x_globals = {
.class = OMAP242X_CLASS,
.tap= OMAP2_L4_IO_ADDRESS(0x48014000),
- .sdrc = OMAP2_L3_IO_ADDRESS(OMAP2420_SDRC_BASE),
- .sms= OMAP2_L3_IO_ADDRESS(OMAP2420_SMS_BASE),
- .ctrl = OMAP2_L4_IO_ADDRESS(OMAP2420_CTRL_BASE),
- .prm= OMAP2_L4_IO_ADDRESS(OMAP2420_PRM_BASE),
- .cm = OMAP2_L4_IO_ADDRESS(OMAP2420_CM_BASE),
+ .sdrc = OMAP2420_SDRC_BASE,
+ .sms= OMAP2420_SMS_BASE,
+ .ctrl = OMAP2420_CTRL_BASE,
+ .prm= OMAP2420_PRM_BASE,
+ .cm = OMAP2420_CM_BASE,
.uart1_phys = OMAP2_UART1_BASE,
.uart2_phys = OMAP2_UART2_BASE,
.uart3_phys = OMAP2_UART3_BASE,
@@ -277,11 +277,11 @@ void __init omap2_set_globals_242x(void)
static struct omap_globals omap243x_globals = {
.class = OMAP243X_CLASS,
.tap= OMAP2_L4_IO_ADDRESS(0x4900a000),
- .sdrc = OMAP2_L3_IO_ADDRESS(OMAP243X_SDRC_BASE),
- .sms= OMAP2_L3_IO_ADDRESS(OMAP243X_SMS_BASE),
- .ctrl = OMAP2_L4_IO_ADDRESS(OMAP243X_CTRL_BASE),
- .prm= OMAP2_L4_IO_ADDRESS(OMAP2430_PRM_BASE),
- .cm = OMAP2_L4_IO_ADDRESS(OMAP2430_CM_BASE),
+ .sdrc = OMAP243X_SDRC_BASE,
+ .sms= (OMAP243X_SMS_BASE),
+ .ctrl = (OMAP243X_CTRL_BASE),
+ .prm= (OMAP2430_PRM_BASE),
+ .cm = (OMAP2430_CM_BASE),
.uart1_phys = OMAP2_UART1_BASE,
.uart2_phys = OMAP2
[PATCH 03/24] omap4: sdma: Enable the idle modes on omap4
This patch enables smart-idle idlemodes and autoidle for sDMA
on OMAP4
Signed-off-by: Santosh Shilimkar
---
arch/arm/plat-omap/dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 30ff525..5ec96db 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2138,7 +2138,7 @@ static int __init omap_init_dma(void)
setup_irq(irq, &omap24xx_dma_irq);
}
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
/* Enable smartidle idlemodes and autoidle */
u32 v = dma_read(OCP_SYSCONFIG);
v &= ~(DMA_SYSCONFIG_MIDLEMODE_MASK |
--
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 16/24] omap4: Add i2c support on omap4 platform
This patch is rebased version of earlier post to add I2C
driver support to OMAP4 platform. On OMAP4, all
I2C register address offsets are changed from OMAP1/2/3 I2C.
In order to not have #ifdef's at various places in code,
as well as to support multi-OMAP build, an array is created
to hold the register addresses with it's offset.
This patch was submitted, reviewed and acked on mailing list
already. For more details refer below link
http://www.mail-archive.com/linux-...@vger.kernel.org/msg02281.html
This version updated on top of 16 bit support added as part of
the commit "8bb209278e555a626f9637e844fe4c1b90e849f6"
Signed-off-by: Syed Rafiuddin
Signed-off-by: Santosh Shilimkar
Acked-by: Kevin Hilman
CC: Tony Lindgren
CC: Ben Dooks
---
arch/arm/plat-omap/i2c.c | 17 -
drivers/i2c/busses/i2c-omap.c | 148 -
2 files changed, 131 insertions(+), 34 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 96d2781..f18d757 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -53,9 +53,15 @@ static struct resource i2c_resources[][2] = {
#ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
{ I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE2, INT_24XX_I2C2_IRQ) },
#endif
+#ifdefined(CONFIG_ARCH_OMAP4)
+ { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE2, INT_44XX_I2C2_IRQ) },
+#endif
#ifdefined(CONFIG_ARCH_OMAP3)
{ I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE3, INT_34XX_I2C3_IRQ) },
#endif
+#ifdefined(CONFIG_ARCH_OMAP4)
+ { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE3, INT_44XX_I2C3_IRQ) },
+#endif
};
#define I2C_DEV_BUILDER(bus_id, res, data) \
@@ -72,10 +78,11 @@ static struct resource i2c_resources[][2] = {
static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
static struct platform_device omap_i2c_devices[] = {
I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_rate[0]),
-#ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
+#ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
+ defined(CONFIG_ARCH_OMAP4)
I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
#endif
-#ifdefined(CONFIG_ARCH_OMAP3)
+#ifdefined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
#endif
};
@@ -90,7 +97,7 @@ static int __init omap_i2c_nr_ports(void)
ports = 1;
else if (cpu_is_omap24xx())
ports = 2;
- else if (cpu_is_omap34xx())
+ else if (cpu_is_omap34xx() || cpu_is_omap44xx())
ports = 3;
return ports;
@@ -112,6 +119,10 @@ static int __init omap_i2c_add_bus(int bus_id)
base = OMAP2_I2C_BASE1;
irq = INT_24XX_I2C1_IRQ;
}
+ if (cpu_is_omap44xx()) {
+ base = OMAP2_I2C_BASE1;
+ irq = INT_44XX_I2C1_IRQ;
+ }
res[0].start = base;
res[0].end = base + OMAP_I2C_SIZE;
res[1].start = irq;
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9c3ce4d..89a156a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -44,29 +44,37 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
#define OMAP_I2C_REV_ON_3430 0x3C
+#define OMAP_I2C_REV_ON_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
-#define OMAP_I2C_REV_REG 0x00
-#define OMAP_I2C_IE_REG0x01
-#define OMAP_I2C_STAT_REG 0x02
-#define OMAP_I2C_IV_REG0x03
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
-#define OMAP_I2C_WE_REG0x03
-#define OMAP_I2C_SYSS_REG 0x04
-#define OMAP_I2C_BUF_REG 0x05
-#define OMAP_I2C_CNT_REG 0x06
-#define OMAP_I2C_DATA_REG 0x07
-#define OMAP_I2C_SYSC_REG 0x08
-#define OMAP_I2C_CON_REG 0x09
-#define OMAP_I2C_OA_REG0x0a
-#define OMAP_I2C_SA_REG0x0b
-#define OMAP_I2C_PSC_REG 0x0c
-#define OMAP_I2C_SCLL_REG 0x0d
-#define OMAP_I2C_SCLH_REG 0x0e
-#define OMAP_I2C_SYSTEST_REG 0x0f
-#define OMAP_I2C_BUFSTAT_REG 0x10
+enum {
+ OMAP_I2C_REV_REG = 0,
+ OMAP_I2C_IE_REG,
+ OMAP_I2C_STAT_REG,
+ OMAP_I2C_IV_REG,
+ OMAP_I2C_WE_REG,
+ OMAP_I2C_SYSS_REG,
+ OMAP_I2C_BUF_REG,
+ OMAP_I2C_CNT_REG,
+ OMAP_I2C_DATA_REG,
+ OMAP_I2C_SYSC_REG,
+ OMAP_I2C_CON_REG,
+ OMAP_I2C_OA_REG,
+ OMAP_I2C_SA_REG,
+ OMAP_I2C_PSC_REG,
+ OMAP_I2C_SCLL_REG,
+ OMAP_I2C_SCLH_REG,
+ OMAP_I2C_SYSTEST_REG,
+ OMAP_I2C_BUFSTAT_REG,
+
[PATCH 04/24] omap: sdma: Limit the secure reserve channel fix for omap3
The commit 'ba50ea7e' reserves DMA channels 0 and 1 on high
security devices, in order to avoid collision between kernel
dma transfers and ROM code dma transfers.
This fix is applicable only for OMAP3 so add an appropriate
check.
Signed-off-by: Santosh Shilimkar
CC: Kalle Jokiniemi
CC: Kevin Hilman
---
arch/arm/plat-omap/dma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 5ec96db..049165c 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2149,7 +2149,8 @@ static int __init omap_init_dma(void)
DMA_SYSCONFIG_AUTOIDLE);
dma_write(v , OCP_SYSCONFIG);
/* reserve dma channels 0 and 1 in high security devices */
- if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
+ if (cpu_is_omap34xx() &&
+ (omap_type() != OMAP2_DEVICE_TYPE_GP)) {
printk(KERN_INFO "Reserving DMA channels 0 and 1 for "
"HS ROM code\n");
dma_chan[0].dev_id = 0;
--
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 13/24] omap4: clocks: Remove clock hacks from timer-gp.c
Now the omap4 clock framework is mainline and clk_get_rate()
is functional. Hence reomve the hardcoded clock hacks.
This patch also fixes
Division by zero in kernel.
Backtrace:
[] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c)
r7:6093 r6:c0641050 r5:c0223e78 r4:c02126b4
[] (dump_stack+0x0/0x1c) from [] (__div0+0x18/0x20)
[] (__div0+0x0/0x20) from [] (Ldiv0+0x8/0x10)
[] (omap_dm_timer_stop+0x0/0xb0) from []
(omap2_gp_timer_set_mode+0x1c/0x68)
r5:c0223e78 r4:
[] (omap2_gp_timer_set_mode+0x0/0x68) from []
(clockevents_set_mode+0x30/0x64)
r5:c020cae0 r4:
[] (clockevents_set_mode+0x0/0x64) from []
(clockevents_exchange_device+0x30/0x9c)
r5:c020cae0 r4:c02146e0
[] (clockevents_exchange_device+0x0/0x9c) from []
(tick_notify+0x17c/0x404)
r7: r6:c0641050 r5: r4:c020cae0
[] (tick_notify+0x0/0x404) from []
(notifier_call_chain+0x34/0x78)
[] (notifier_call_chain+0x0/0x78) from []
(__raw_notifier_call_chain+0x1c/0x24)
[] (__raw_notifier_call_chain+0x0/0x24) from []
(raw_notifier_call_chain+0x20/0x28)
[] (raw_notifier_call_chain+0x0/0x28) from []
(clockevents_do_notify+0x1c/0x24)
[] (clockevents_do_notify+0x0/0x24) from []
(clockevents_register_device+0x98/0xd0)
[] (clockevents_register_device+0x0/0xd0) from []
(percpu_timer_setup+0x80/0x9c)
r7: r6:0002 r5:0002 r4:0003
[] (percpu_timer_setup+0x0/0x9c) from []
(smp_prepare_cpus+0xb0/0xe8)
[] (smp_prepare_cpus+0x0/0xe8) from []
(kernel_init+0x5c/0x1fc)
r7: r6: r5: r4:c001b8a4
[] (kernel_init+0x0/0x1fc) from [] (do_exit+0x0/0x604)
r7: r6: r5: r4:
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/timer-gp.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index cd04dea..74fbed8 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -85,8 +85,6 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
case CLOCK_EVT_MODE_PERIODIC:
period = clk_get_rate(omap_dm_timer_get_fclk(gptimer)) / HZ;
period -= 1;
- if (cpu_is_omap44xx())
- period = 0xff; /* FIXME: */
omap_dm_timer_set_load_start(gptimer, 1, 0x - period);
break;
case CLOCK_EVT_MODE_ONESHOT:
@@ -150,9 +148,6 @@ static void __init omap2_gp_clockevent_init(void)
"timer-gp: omap_dm_timer_set_source() failed\n");
tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer));
- if (cpu_is_omap44xx())
- /* Assuming 32kHz clk is driving GPT1 */
- tick_rate = 32768; /* FIXME: */
pr_info("OMAP clockevent source: GPTIMER%d at %u Hz\n",
gptimer_id, tick_rate);
--
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 19/24] twl6030: Fix vsel calculations in set/get voltage api's
From: Rajendra Nayak
TWL6030 has a formula to be used to calculate the vsel values
to be programmed in the VREG_VOLTAGE registers.
Voltage(in mV) = 1000mv + 100mv * (vsel - 1)
Ex: if vsel = 0x9, mV = 1000 + 100 * (9 -1) = 1800mV.
Signed-off-by: Rajendra Nayak
Cc: Liam Girdwood
Cc: Samuel Ortiz
---
drivers/regulator/twl-regulator.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 7e67485..a5ca794 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -367,11 +367,17 @@ twlldo_set_voltage(struct regulator_dev *rdev, int
min_uV, int max_uV)
/* REVISIT for VAUX2, first match may not be best/lowest */
/* use the first in-range value */
- if (min_uV <= uV && uV <= max_uV)
+ if (min_uV <= uV && uV <= max_uV) {
+ if (twl_class_is_6030())
+ /*
+* Use the below formula to calculate vsel
+* mV = 1000mv + 100mv * (vsel - 1)
+*/
+ vsel = (mV - 1000)/100 + 1;
return twlreg_write(info, TWL_MODULE_PM_RECEIVER,
VREG_VOLTAGE, vsel);
+ }
}
-
return -EDOM;
}
@@ -384,8 +390,17 @@ static int twlldo_get_voltage(struct regulator_dev *rdev)
if (vsel < 0)
return vsel;
- vsel &= info->table_len - 1;
- return LDO_MV(info->table[vsel]) * 1000;
+ if (twl_class_is_4030()) {
+ vsel &= info->table_len - 1;
+ return LDO_MV(info->table[vsel]) * 1000;
+ } else if (twl_class_is_6030()) {
+ /*
+* Use the below formula to calculate vsel
+* mV = 1000mv + 100mv * (vsel - 1)
+*/
+ return (1000 + (100 * (vsel - 1))) * 1000;
+ }
+ return -EDOM;
}
static struct regulator_ops twlldo_ops = {
--
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 17/24] omap4: Add i2c board support for omap4 platform
This patch enables I2C driver for OMAP4430 SDP board file.
Signed-off-by: Santosh Shilimkar
---
arch/arm/configs/omap_4430sdp_defconfig | 19 +--
arch/arm/mach-omap2/board-4430sdp.c |9 +
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/arm/configs/omap_4430sdp_defconfig
b/arch/arm/configs/omap_4430sdp_defconfig
index 7ac3fbf..d791e63 100644
--- a/arch/arm/configs/omap_4430sdp_defconfig
+++ b/arch/arm/configs/omap_4430sdp_defconfig
@@ -453,8 +453,23 @@ CONFIG_HW_RANDOM=y
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
-# CONFIG_I2C is not set
-# CONFIG_SPI is not set
+CONFIG_I2C=y
+CONFIG_I2C_BOARDINFO=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_HELPER_AUTO=y
+
+#
+# I2C Hardware Bus support
+#
+
+#
+# I2C system bus drivers (mostly embedded / system-on-chip)
+#
+# CONFIG_I2C_DESIGNWARE is not set
+# CONFIG_I2C_GPIO is not set
+# CONFIG_I2C_OCORES is not set
+CONFIG_I2C_OMAP=y
+# CONFIG_I2C_SIMTEC is not set
#
# PPS support
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 86b240e..a325ba5 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -81,8 +81,17 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
+static int __init omap4_i2c_init(void)
+{
+ /* Phoenix Audio IC needs I2C1 to start with 400 KHz and less */
+ omap_register_i2c_bus(1, 400, NULL, 0);
+ omap_register_i2c_bus(2, 400, NULL, 0);
+ omap_register_i2c_bus(3, 400, NULL, 0);
+ return 0;
+}
static void __init omap_4430sdp_init(void)
{
+ omap4_i2c_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
/* OMAP4 SDP uses internal transceiver so register nop transceiver */
--
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 20/24] twl6030: add base addr for ID0, ID1, ID2
From: Balaji T K
Add base address for generic slave ID0, ID1, ID2
and introduced one more entry to align RTC module number between
twl4030 and twl6030
Cc: Samuel Ortiz
Signed-off-by: Balaji T K
---
drivers/mfd/twl-core.c |7 +--
include/linux/i2c/twl.h |5 +
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 2a76065..d820e87 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -204,6 +204,7 @@
/* subchip/slave 3 0x4B - AUDIO */
#define TWL6030_BASEADD_AUDIO 0x
#define TWL6030_BASEADD_RSV0x
+#define TWL6030_BASEADD_ZERO 0x
/* Few power values */
#define R_CFG_BOOT 0x05
@@ -319,9 +320,11 @@ static struct twl_mapping twl6030_map[] = {
{ SUB_CHIP_ID1, TWL6030_BASEADD_CHARGER },
{ SUB_CHIP_ID1, TWL6030_BASEADD_GASGAUGE },
{ SUB_CHIP_ID1, TWL6030_BASEADD_PWM },
- { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
- { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
+ { SUB_CHIP_ID0, TWL6030_BASEADD_ZERO },
+ { SUB_CHIP_ID1, TWL6030_BASEADD_ZERO },
+ { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
+ { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
{ SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
{ SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
{ SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index bf1c5be..fcf9286 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -80,6 +80,11 @@
#define TWL_MODULE_PM_MASTER TWL4030_MODULE_PM_MASTER
#define TWL_MODULE_PM_RECEIVER TWL4030_MODULE_PM_RECEIVER
#define TWL_MODULE_RTC TWL4030_MODULE_RTC
+#define TWL_MODULE_PWM TWL4030_MODULE_PWM0
+
+#define TWL6030_MODULE_ID0 0x0D
+#define TWL6030_MODULE_ID1 0x0E
+#define TWL6030_MODULE_ID2 0x0F
#define GPIO_INTR_OFFSET 0
#define KEYPAD_INTR_OFFSET 1
--
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 08/24] omap4: clocks: Make Uart driver's clock calls OMAP4 compatible
From: Abhijit Pagare
The uart driver has been adapted for the OMAP4 way of clock calls.
Signed-off-by: Abhijit Pagare
---
arch/arm/mach-omap2/serial.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..97859b0 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -257,7 +257,8 @@ static inline void omap_uart_enable_clocks(struct
omap_uart_state *uart)
return;
clk_enable(uart->ick);
- clk_enable(uart->fck);
+ if (!cpu_is_omap44xx())
+ clk_enable(uart->fck);
uart->clocked = 1;
omap_uart_restore_context(uart);
}
@@ -272,7 +273,8 @@ static inline void omap_uart_disable_clocks(struct
omap_uart_state *uart)
omap_uart_save_context(uart);
uart->clocked = 0;
clk_disable(uart->ick);
- clk_disable(uart->fck);
+ if (!cpu_is_omap44xx())
+ clk_disable(uart->fck);
}
static void omap_uart_enable_wakeup(struct omap_uart_state *uart)
@@ -669,18 +671,24 @@ void __init omap_serial_early_init(void)
continue;
}
- sprintf(name, "uart%d_ick", i+1);
+ if (!cpu_is_omap44xx())
+ sprintf(name, "uart%d_ick", i+1);
+ else
+ sprintf(name, "uart%d_ck", i+1);
uart->ick = clk_get(NULL, name);
if (IS_ERR(uart->ick)) {
printk(KERN_ERR "Could not get uart%d_ick\n", i+1);
uart->ick = NULL;
}
- sprintf(name, "uart%d_fck", i+1);
- uart->fck = clk_get(NULL, name);
- if (IS_ERR(uart->fck)) {
- printk(KERN_ERR "Could not get uart%d_fck\n", i+1);
- uart->fck = NULL;
+ if (!cpu_is_omap44xx()) {
+ sprintf(name, "uart%d_fck", i+1);
+ uart->fck = clk_get(NULL, name);
+ if (IS_ERR(uart->fck)) {
+ printk(KERN_ERR "Could not get uart%d_fck\n",
+i+1);
+ uart->fck = NULL;
+ }
}
/* FIXME: Remove this once the clkdev is ready */
--
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 07/24] omap 3/4: Remove overlapping mapping of L4_WKUP io space
This patch removes the L4 wakeup io mapping section for omap3d
and omap4. L4 wakeup space is part of 4MB L4 space which is
already mapped and hence remove the overlapped mapping.
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/io.c | 12
arch/arm/plat-omap/include/plat/io.h |9 -
arch/arm/plat-omap/io.c |4
3 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 5a3d6f9..0385a28 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -140,12 +140,6 @@ static struct map_desc omap34xx_io_desc[] __initdata = {
.type = MT_DEVICE
},
{
- .virtual= L4_WK_34XX_VIRT,
- .pfn= __phys_to_pfn(L4_WK_34XX_PHYS),
- .length = L4_WK_34XX_SIZE,
- .type = MT_DEVICE
- },
- {
.virtual= OMAP34XX_GPMC_VIRT,
.pfn= __phys_to_pfn(OMAP34XX_GPMC_PHYS),
.length = OMAP34XX_GPMC_SIZE,
@@ -192,12 +186,6 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
.type = MT_DEVICE,
},
{
- .virtual= L4_WK_44XX_VIRT,
- .pfn= __phys_to_pfn(L4_WK_44XX_PHYS),
- .length = L4_WK_44XX_SIZE,
- .type = MT_DEVICE,
- },
- {
.virtual= OMAP44XX_GPMC_VIRT,
.pfn= __phys_to_pfn(OMAP44XX_GPMC_PHYS),
.length = OMAP44XX_GPMC_SIZE,
diff --git a/arch/arm/plat-omap/include/plat/io.h
b/arch/arm/plat-omap/include/plat/io.h
index eef914d..128b549 100644
--- a/arch/arm/plat-omap/include/plat/io.h
+++ b/arch/arm/plat-omap/include/plat/io.h
@@ -158,10 +158,6 @@
* VPOM3430 was not working for Int controller
*/
-#define L4_WK_34XX_PHYSL4_WK_34XX_BASE /* 0x4830 -->
0xfa30 */
-#define L4_WK_34XX_VIRT(L4_WK_34XX_PHYS + OMAP2_L4_IO_OFFSET)
-#define L4_WK_34XX_SIZESZ_1M
-
#define L4_PER_34XX_PHYS L4_PER_34XX_BASE
/* 0x4900 --> 0xfb00 */
#define L4_PER_34XX_VIRT (L4_PER_34XX_PHYS + OMAP2_L4_IO_OFFSET)
@@ -204,11 +200,6 @@
#define L4_44XX_VIRT (L4_44XX_PHYS + OMAP2_L4_IO_OFFSET)
#define L4_44XX_SIZE SZ_4M
-
-#define L4_WK_44XX_PHYSL4_WK_44XX_BASE /* 0x4a30 -->
0xfc30 */
-#define L4_WK_44XX_VIRT(L4_WK_44XX_PHYS + OMAP2_L4_IO_OFFSET)
-#define L4_WK_44XX_SIZESZ_1M
-
#define L4_PER_44XX_PHYS L4_PER_44XX_BASE
/* 0x4800 --> 0xfa00 */
#define L4_PER_44XX_VIRT (L4_PER_44XX_PHYS + OMAP2_L4_IO_OFFSET)
diff --git a/arch/arm/plat-omap/io.c b/arch/arm/plat-omap/io.c
index 0cfd54f..2c494cf 100644
--- a/arch/arm/plat-omap/io.c
+++ b/arch/arm/plat-omap/io.c
@@ -90,8 +90,6 @@ void __iomem *omap_ioremap(unsigned long p, size_t size,
unsigned int type)
return XLATE(p, L3_34XX_PHYS, L3_34XX_VIRT);
if (BETWEEN(p, L4_34XX_PHYS, L4_34XX_SIZE))
return XLATE(p, L4_34XX_PHYS, L4_34XX_VIRT);
- if (BETWEEN(p, L4_WK_34XX_PHYS, L4_WK_34XX_SIZE))
- return XLATE(p, L4_WK_34XX_PHYS, L4_WK_34XX_VIRT);
if (BETWEEN(p, OMAP34XX_GPMC_PHYS, OMAP34XX_GPMC_SIZE))
return XLATE(p, OMAP34XX_GPMC_PHYS, OMAP34XX_GPMC_VIRT);
if (BETWEEN(p, OMAP343X_SMS_PHYS, OMAP343X_SMS_SIZE))
@@ -110,8 +108,6 @@ void __iomem *omap_ioremap(unsigned long p, size_t size,
unsigned int type)
return XLATE(p, L3_44XX_PHYS, L3_44XX_VIRT);
if (BETWEEN(p, L4_44XX_PHYS, L4_44XX_SIZE))
return XLATE(p, L4_44XX_PHYS, L4_44XX_VIRT);
- if (BETWEEN(p, L4_WK_44XX_PHYS, L4_WK_44XX_SIZE))
- return XLATE(p, L4_WK_44XX_PHYS, L4_WK_44XX_VIRT);
if (BETWEEN(p, OMAP44XX_GPMC_PHYS, OMAP44XX_GPMC_SIZE))
return XLATE(p, OMAP44XX_GPMC_PHYS, OMAP44XX_GPMC_VIRT);
if (BETWEEN(p, OMAP44XX_EMIF1_PHYS, OMAP44XX_EMIF1_SIZE))
--
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 01/24] omap 3/4: uart: fix full-fifo write abort
This patch is addition to the already merged commit on non-empty
uart fifo read abort. "ce13d4716a276f4331d78ba28a5093a63822ab95"
OMAP3630 and OMAP4430 UART IP blocks have a restriction on TX FIFO
too. If you try to write to the tx fifo when it is full, the system aborts.
This can be easily reproducible by not suppressing interconnect errors or
long duration testing where continuous prints over console from multiple
threads. This patch is addressing the issue by ensuring that write is
not issued while fifo is full. A timeout is added to avoid any hang
on fifo-full for 10 mS which is unlikely case.
Patch is validated on OMAP3630 and OMAP4 SDP.
V2 version removed the additional 1 uS on every TX as per
Tony's suggestion
Signed-off-by: Woodruff Richard
Signed-off-by: Santosh Shilimkar
CC: Ghorai Sukumar
---
arch/arm/mach-omap2/serial.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5f3035e..b79bc89 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -160,6 +161,13 @@ static inline unsigned int serial_read_reg(struct
plat_serial8250_port *up,
return (unsigned int)__raw_readb(up->membase + offset);
}
+static inline void __serial_write_reg(struct uart_port *up, int offset,
+ int value)
+{
+ offset <<= up->regshift;
+ __raw_writeb(value, up->membase + offset);
+}
+
static inline void serial_write_reg(struct plat_serial8250_port *p, int offset,
int value)
{
@@ -620,6 +628,20 @@ static unsigned int serial_in_override(struct uart_port
*up, int offset)
return __serial_read_reg(up, offset);
}
+static void serial_out_override(struct uart_port *up, int offset, int value)
+{
+ unsigned int status, tmout = 1;
+
+ status = __serial_read_reg(up, UART_LSR);
+ while (!(status & UART_LSR_THRE)) {
+ /* Wait up to 10ms for the character(s) to be sent. */
+ if (--tmout == 0)
+ break;
+ udelay(1);
+ status = __serial_read_reg(up, UART_LSR);
+ }
+ __serial_write_reg(up, offset, value);
+}
void __init omap_serial_early_init(void)
{
int i;
@@ -721,11 +743,14 @@ void __init omap_serial_init_port(int port)
* omap3xxx: Never read empty UART fifo on UARTs
* with IP rev >=0x52
*/
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
uart->p->serial_in = serial_in_override;
- else if ((serial_read_reg(uart->p, UART_OMAP_MVER) & 0xFF)
- >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ uart->p->serial_out = serial_out_override;
+ } else if ((serial_read_reg(uart->p, UART_OMAP_MVER) & 0xFF)
+ >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) {
uart->p->serial_in = serial_in_override;
+ uart->p->serial_out = serial_out_override;
+ }
}
/**
--
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 11/24] omap4: clocks: Make watchdog driver's clock calls OMAP4 compatible
The watchdog driver has been adapted for the OMAP4 way of clock calls.
In OMAP4, WDT iclk are hw controlled and no sw control is available
Signed-off-by: Abhijit Pagare
---
drivers/watchdog/omap_wdt.c | 39 +++
1 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index c6aaf28..df9f714 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -145,7 +145,9 @@ static int omap_wdt_open(struct inode *inode, struct file
*file)
if (test_and_set_bit(1, (unsigned long *)&(wdev->omap_wdt_users)))
return -EBUSY;
- clk_enable(wdev->ick);/* Enable the interface clock */
+ /* OMAP4 iclk are hw controlled and no sw control is available */
+ if (!cpu_is_omap44xx())
+ clk_enable(wdev->ick);/* Enable the interface clock */
clk_enable(wdev->fck);/* Enable the functional clock */
/* initialize prescaler */
@@ -176,7 +178,9 @@ static int omap_wdt_release(struct inode *inode, struct
file *file)
omap_wdt_disable(wdev);
- clk_disable(wdev->ick);
+ /* OMAP4 iclk are hw controlled and no sw control is available */
+ if (!cpu_is_omap44xx())
+ clk_disable(wdev->ick);
clk_disable(wdev->fck);
#else
printk(KERN_CRIT "omap_wdt: Unexpected close, not stopping!\n");
@@ -292,11 +296,14 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
wdev->omap_wdt_users = 0;
wdev->mem = mem;
- wdev->ick = clk_get(&pdev->dev, "ick");
- if (IS_ERR(wdev->ick)) {
- ret = PTR_ERR(wdev->ick);
- wdev->ick = NULL;
- goto err_clk;
+ /* OMAP4 iclk are hw controlled and no sw control is available */
+ if (!cpu_is_omap44xx()) {
+ wdev->ick = clk_get(&pdev->dev, "ick");
+ if (IS_ERR(wdev->ick)) {
+ ret = PTR_ERR(wdev->ick);
+ wdev->ick = NULL;
+ goto err_clk;
+ }
}
wdev->fck = clk_get(&pdev->dev, "fck");
if (IS_ERR(wdev->fck)) {
@@ -313,7 +320,9 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, wdev);
- clk_enable(wdev->ick);
+ /* OMAP4 iclk are hw controlled and no sw control is available */
+ if (!cpu_is_omap44xx())
+ clk_enable(wdev->ick);
clk_enable(wdev->fck);
omap_wdt_disable(wdev);
@@ -335,7 +344,9 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
/* autogate OCP interface clock */
__raw_writel(0x01, wdev->base + OMAP_WATCHDOG_SYS_CONFIG);
- clk_disable(wdev->ick);
+ /* OMAP4 iclk are hw controlled and no sw control is available */
+ if (!cpu_is_omap44xx())
+ clk_disable(wdev->ick);
clk_disable(wdev->fck);
omap_wdt_dev = pdev;
@@ -350,8 +361,10 @@ err_ioremap:
wdev->base = NULL;
err_clk:
- if (wdev->ick)
- clk_put(wdev->ick);
+ /* OMAP4 iclk are hw controlled and no sw control is available */
+ if (!cpu_is_omap44xx())
+ if (wdev->ick)
+ clk_put(wdev->ick);
if (wdev->fck)
clk_put(wdev->fck);
kfree(wdev);
@@ -385,7 +398,9 @@ static int __devexit omap_wdt_remove(struct platform_device
*pdev)
release_mem_region(res->start, resource_size(res));
platform_set_drvdata(pdev, NULL);
- clk_put(wdev->ick);
+ /* OMAP4 iclk are hw controlled and no sw control is available */
+ if (!cpu_is_omap44xx())
+ clk_put(wdev->ick);
clk_put(wdev->fck);
iounmap(wdev->base);
--
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 06/24] omap4: Fix omap_type() for omap4
This patch fixes the omap_type function to detect whether the device
is GP or HS
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/id.c |2 ++
arch/arm/plat-omap/include/plat/control.h |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 9e7c4ae..e73f7e4 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -57,6 +57,8 @@ int omap_type(void)
val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
} else if (cpu_is_omap34xx()) {
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
+ } else if (cpu_is_omap44xx()) {
+ val = omap_ctrl_readl(OMAP44XX_CONTROL_STATUS);
} else {
pr_err("Cannot detect omap type!\n");
goto out;
diff --git a/arch/arm/plat-omap/include/plat/control.h
b/arch/arm/plat-omap/include/plat/control.h
index 2074473..a56deee 100644
--- a/arch/arm/plat-omap/include/plat/control.h
+++ b/arch/arm/plat-omap/include/plat/control.h
@@ -204,6 +204,9 @@
#define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
#define OMAP3_PADCONF_SAD2D_IDLEACK0x254
+/* 44xx control status register offset */
+#define OMAP44XX_CONTROL_STATUS0x2c4
+
/*
* REVISIT: This list of registers is not comprehensive - there are more
* that should be added.
--
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 10/24] omap4: clokcs: Make gpio driver's clock calls OMAP4 compatible
From: Abhijit Pagare
The gpio driver has been adapted for the OMAP4 way of clock calls.
Signed-off-by: Abhijit Pagare
---
arch/arm/plat-omap/gpio.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 6055028..5ae7a5a 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1724,7 +1724,10 @@ static int __init _omap_gpio_init(void)
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
for (i = 0; i < OMAP34XX_NR_GPIOS; i++) {
- sprintf(clk_name, "gpio%d_ick", i + 1);
+ if (!cpu_is_omap44xx())
+ sprintf(clk_name, "gpio%d_ick", i + 1);
+ else
+ sprintf(clk_name, "gpio%d_ck", i + 1);
gpio_iclks[i] = clk_get(NULL, clk_name);
if (IS_ERR(gpio_iclks[i]))
printk(KERN_ERR "Could not get %s\n", clk_name);
@@ -1891,7 +1894,7 @@ static int __init _omap_gpio_init(void)
set_irq_chained_handler(bank->irq, gpio_irq_handler);
set_irq_data(bank->irq, bank);
- if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
+ if (cpu_is_omap34xx()) {
sprintf(clk_name, "gpio%d_dbck", i + 1);
bank->dbck = clk_get(NULL, clk_name);
if (IS_ERR(bank->dbck))
--
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 23/24] omap4: Enable RTC and regulator support
From: Balaji T K This patch enables RTC and regulator support on omap4430 sdp platform. These are i2c slave devices and hence kernel needs i2c driver suport to make it work. Signed-off-by: Balaji T K Signed-off-by: Santosh Shilimkar --- arch/arm/configs/omap_4430sdp_defconfig | 20 ++-- 1 files changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index d791e63..339b154 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -520,11 +520,12 @@ CONFIG_SSB_POSSIBLE=y # CONFIG_MFD_ASIC3 is not set # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_PASIC3 is not set +CONFIG_TWL4030_CORE=y # CONFIG_MFD_TMIO is not set # CONFIG_MFD_T7L66XB is not set # CONFIG_MFD_TC6387XB is not set # CONFIG_MFD_TC6393XB is not set -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_MEDIA_SUPPORT is not set # @@ -553,12 +554,27 @@ CONFIG_DUMMY_CONSOLE=y # CONFIG_NEW_LEDS is not set # CONFIG_ACCESSIBILITY is not set CONFIG_RTC_LIB=y -# CONFIG_RTC_CLASS is not set +CONFIG_RTC_CLASS=y +CONFIG_RTC_HCTOSYS=y +CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_DMADEVICES is not set # CONFIG_AUXDISPLAY is not set # CONFIG_UIO is not set # +# RTC interfaces +# +CONFIG_RTC_INTF_SYSFS=y +CONFIG_RTC_INTF_PROC=y +CONFIG_RTC_INTF_DEV=y + +# +# I2C TWL drivers +# +CONFIG_RTC_DRV_TWL4030=y +CONFIG_REGULATOR_TWL4030=y + +# # TI VLYNQ # # CONFIG_STAGING is not set -- 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 18/24] omap4: clocks: Make i2c driver's clock calls OMAP4 compatible
From: Abhijit Pagare
The i2c driver has been adapted for the OMAP4 way of clock calls.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Abhijit Pagare
---
drivers/i2c/busses/i2c-omap.c | 29 -
1 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 89a156a..d4f6eda 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -260,11 +260,14 @@ static int __init omap_i2c_get_clocks(struct omap_i2c_dev
*dev)
{
int ret;
- dev->iclk = clk_get(dev->dev, "ick");
- if (IS_ERR(dev->iclk)) {
- ret = PTR_ERR(dev->iclk);
- dev->iclk = NULL;
- return ret;
+ /* OMAP4 iclk are hw controlled and no sw control is available */
+ if (!cpu_is_omap44xx()) {
+ dev->iclk = clk_get(dev->dev, "ick");
+ if (IS_ERR(dev->iclk)) {
+ ret = PTR_ERR(dev->iclk);
+ dev->iclk = NULL;
+ return ret;
+ }
}
dev->fclk = clk_get(dev->dev, "fck");
@@ -285,15 +288,18 @@ static void omap_i2c_put_clocks(struct omap_i2c_dev *dev)
{
clk_put(dev->fclk);
dev->fclk = NULL;
- clk_put(dev->iclk);
- dev->iclk = NULL;
+ if (!cpu_is_omap44xx()) {
+ clk_put(dev->iclk);
+ dev->iclk = NULL;
+ }
}
static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
WARN_ON(!dev->idle);
- clk_enable(dev->iclk);
+ if (!cpu_is_omap44xx())
+ clk_enable(dev->iclk);
clk_enable(dev->fclk);
if (cpu_is_omap34xx()) {
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
@@ -337,7 +343,8 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
}
dev->idle = 1;
clk_disable(dev->fclk);
- clk_disable(dev->iclk);
+ if (!cpu_is_omap44xx())
+ clk_disable(dev->iclk);
}
static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -434,10 +441,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
internal_clk = 9600;
else
internal_clk = 4000;
- /* FIXME: Remove this once clock framework is available*/
- if (dev->rev >= OMAP_I2C_REV_ON_4430)
- fclk_rate = 96000;
- else
fclk_rate = clk_get_rate(dev->fclk) / 1000;
/* Compute prescaler divisor */
--
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 14/24] omap4: Enable WDT and McBSP support
This patch enables watchdog timer and McBSP support on omap4430 sdp platform. Additinaly the uart3 made as default console in the omap_4430sdp_defconfig Signed-off-by: Balaji T K Signed-off-by: Santosh Shilimkar --- arch/arm/configs/omap_4430sdp_defconfig |7 --- drivers/watchdog/Kconfig|6 +++--- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 3de640a..7ac3fbf 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -199,7 +199,7 @@ CONFIG_ARCH_OMAP4=y # # CONFIG_OMAP_RESET_CLOCKS is not set # CONFIG_OMAP_MUX is not set -# CONFIG_OMAP_MCBSP is not set +CONFIG_OMAP_MCBSP=y # CONFIG_OMAP_MBOX_FWK is not set # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y @@ -304,7 +304,7 @@ CONFIG_ALIGNMENT_TRAP=y # CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 -CONFIG_CMDLINE="root=/dev/ram0 rw mem=128M console=ttyS0,115200n8 initrd=0x8160,20M ramdisk_size=20480" +CONFIG_CMDLINE="root=/dev/ram0 rw mem=128M console=ttyS2,115200n8 initrd=0x8160,20M ramdisk_size=20480" # CONFIG_XIP_KERNEL is not set # CONFIG_KEXEC is not set @@ -488,7 +488,8 @@ CONFIG_GPIOLIB=y # CONFIG_POWER_SUPPLY is not set # CONFIG_HWMON is not set # CONFIG_THERMAL is not set -# CONFIG_WATCHDOG is not set +CONFIG_WATCHDOG=y +CONFIG_OMAP_WATCHDOG=y CONFIG_SSB_POSSIBLE=y # diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 3da3f48..1185f05 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -194,10 +194,10 @@ config EP93XX_WATCHDOG config OMAP_WATCHDOG tristate "OMAP Watchdog" - depends on ARCH_OMAP16XX || ARCH_OMAP2 || ARCH_OMAP3 + depends on ARCH_OMAP16XX || ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 help - Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430 watchdog. Say 'Y' - here to enable the OMAP1610/OMAP1710/OMAP2420/OMAP3430 watchdog timer. + Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog. Say 'Y' + here to enable the OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog timer. config PNX4008_WATCHDOG tristate "PNX4008 Watchdog" -- 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 12/24] omap4: clocks: Make dmtimer clocks calls OMAP4 compatible
The gptimer library has been adapted for the OMAP4 way of clock calls.
In OMAP4, the iclk are hw controlled and no sw control is available.
Signed-off-by: Santosh Shilimkar
---
arch/arm/plat-omap/dmtimer.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 24bf692..e4bfeed 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -428,7 +428,9 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer)
#ifdef CONFIG_ARCH_OMAP2PLUS
if (cpu_class_is_omap2()) {
clk_enable(timer->fclk);
- clk_enable(timer->iclk);
+ /* OMAP4 iclk are hw controlled and no sw control available */
+ if (!cpu_is_omap44xx())
+ clk_enable(timer->iclk);
}
#endif
@@ -443,7 +445,9 @@ void omap_dm_timer_disable(struct omap_dm_timer *timer)
#ifdef CONFIG_ARCH_OMAP2PLUS
if (cpu_class_is_omap2()) {
- clk_disable(timer->iclk);
+ /* OMAP4 iclk are hw controlled and no sw control available */
+ if (!cpu_is_omap44xx())
+ clk_disable(timer->iclk);
clk_disable(timer->fclk);
}
#endif
@@ -781,10 +785,19 @@ int __init omap_dm_timer_init(void)
#ifdef CONFIG_ARCH_OMAP2PLUS
if (cpu_class_is_omap2()) {
char clk_name[16];
- sprintf(clk_name, "gpt%d_ick", i + 1);
- timer->iclk = clk_get(NULL, clk_name);
- sprintf(clk_name, "gpt%d_fck", i + 1);
- timer->fclk = clk_get(NULL, clk_name);
+ /*
+* OMAP4 iclks are hw controlled and no sw control
+* is available
+*/
+ if (cpu_is_omap44xx()) {
+ sprintf(clk_name, "gptimer%d_ck", i + 1);
+ timer->fclk = clk_get(NULL, clk_name);
+ } else {
+ sprintf(clk_name, "gpt%d_ick", i + 1);
+ timer->iclk = clk_get(NULL, clk_name);
+ sprintf(clk_name, "gpt%d_fck", i + 1);
+ timer->fclk = clk_get(NULL, clk_name);
+ }
}
#endif
}
--
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 22/24] omap4: add regulator board data for TWL6030
From: Balaji T K
add TWL6030 regulator board data in board-4430sdp.c
Signed-off-by: Rajendra Nayak
Signed-off-by: Balaji T K
---
arch/arm/mach-omap2/board-4430sdp.c | 161 +++
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ad0a9a5..cbdbfa4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -49,6 +50,25 @@ static struct omap_board_config_kernel sdp4430_config[]
__initdata = {
{ OMAP_TAG_LCD, &sdp4430_lcd_config },
};
+
+static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
+ {
+ .supply = "vmmc",
+ },
+ {
+ .supply = "vmmc",
+ },
+ {
+ .supply = "vmmc",
+ },
+ {
+ .supply = "vmmc",
+ },
+ {
+ .supply = "vmmc",
+ },
+};
+
static void __init gic_init_irq(void)
{
void __iomem *base;
@@ -82,9 +102,150 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
+static struct regulator_init_data sdp4430_vaux1 = {
+ .constraints = {
+ .min_uV = 100,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vaux2 = {
+ .constraints = {
+ .min_uV = 120,
+ .max_uV = 280,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vaux3 = {
+ .constraints = {
+ .min_uV = 100,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+/* VMMC1 for MMC1 card */
+static struct regulator_init_data sdp4430_vmmc = {
+ .constraints = {
+ .min_uV = 120,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 5,
+ .consumer_supplies = sdp4430_vmmc_supply,
+};
+
+static struct regulator_init_data sdp4430_vpp = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 250,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vusim = {
+ .constraints = {
+ .min_uV = 120,
+ .max_uV = 290,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vana = {
+ .constraints = {
+ .min_uV = 210,
+ .max_uV = 210,
+ .apply_uV = true,
+
[PATCH 24/24] omap4: multi-omap: Allow build to work
The musb support is enable to omap3 platforms. For omap4 only board support is available and the driver still isn't supported. Because of this build with omap3_defconfig used for multi-omap doesn't work on omap4430 sdp. This patch hacks the musb probe to keep the multi-omap build working on omap4430 sdp Signed-off-by: Santosh Shilimkar --- drivers/usb/musb/musb_core.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index bcce8e8..13b1c4a 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2124,6 +2124,10 @@ static int __init musb_probe(struct platform_device *pdev) struct resource *iomem; void __iomem*base; + /* FIXME: multi-omap build to work on omap4 */ + if (cpu_is_omap44xx()) + return 0; + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!iomem || irq == 0) return -ENODEV; -- 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 21/24] omap4: add i2c1 peripherals data
From: Balaji T K
This patch adds i2c1 peripherals data to
omap4 board file.
Signed-off-by: Balaji T K
---
arch/arm/mach-omap2/board-4430sdp.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index a325ba5..ad0a9a5 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -81,10 +82,25 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
+static struct twl4030_platform_data sdp4430_twldata = {
+ .irq_base = TWL6030_IRQ_BASE,
+ .irq_end= TWL6030_IRQ_END,
+};
+
+static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
+ {
+ I2C_BOARD_INFO("twl6030", 0x48),
+ .flags = I2C_CLIENT_WAKE,
+ .irq = INT_44XX_SYS_NIRQ,
+ .platform_data = &sdp4430_twldata,
+ },
+};
+
static int __init omap4_i2c_init(void)
{
/* Phoenix Audio IC needs I2C1 to start with 400 KHz and less */
- omap_register_i2c_bus(1, 400, NULL, 0);
+ omap_register_i2c_bus(1, 400, sdp4430_i2c_boardinfo,
+ ARRAY_SIZE(sdp4430_i2c_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, NULL, 0);
return 0;
--
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 09/24] omap4: clocks: Make mcbsp driver's clock calls OMAP4 compatible
The mcbsp driver has been adapted for the OMAP4 way of clock calls.
In OMAP4, the iclk are hw controlled and no sw control is available
Signed-off-by: Abhijit Pagare
Signed-off-by: Santosh Shilimkar
---
arch/arm/plat-omap/mcbsp.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 473be3d..72b9694 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -1314,11 +1314,14 @@ static int __devinit omap_mcbsp_probe(struct
platform_device *pdev)
mcbsp->dma_rx_sync = pdata->dma_rx_sync;
mcbsp->dma_tx_sync = pdata->dma_tx_sync;
- mcbsp->iclk = clk_get(&pdev->dev, "ick");
- if (IS_ERR(mcbsp->iclk)) {
- ret = PTR_ERR(mcbsp->iclk);
- dev_err(&pdev->dev, "unable to get ick: %d\n", ret);
- goto err_iclk;
+ /* OMAP4 iclk are hw controlled and no sw control is available */
+ if (!cpu_is_omap44xx()) {
+ mcbsp->iclk = clk_get(&pdev->dev, "ick");
+ if (IS_ERR(mcbsp->iclk)) {
+ ret = PTR_ERR(mcbsp->iclk);
+ dev_err(&pdev->dev, "unable to get ick: %d\n", ret);
+ goto err_iclk;
+ }
}
mcbsp->fclk = clk_get(&pdev->dev, "fck");
--
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 05/24] omap4: Add needed IRQ line into irqs.h
This patch adds DSS, keyboard and ducati irq entries in irqs.h Ones omap4 hwmod is pushed on mainlie, all the irqs lines data would be availabe. Signed-off-by: Santosh Shilimkar --- arch/arm/plat-omap/include/plat/irqs.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h index e8205c1..e2fbd74 100644 --- a/arch/arm/plat-omap/include/plat/irqs.h +++ b/arch/arm/plat-omap/include/plat/irqs.h @@ -385,6 +385,7 @@ #define INT_44XX_GPTIMER11 (47 + IRQ_GIC_START) #define INT_44XX_GPTIMER12 (95 + IRQ_GIC_START) #define INT_44XX_SHA1MD5 (51 + IRQ_GIC_START) +#define INT_44XX_DSS_DSI1 (53 + IRQ_GIC_START) #define INT_44XX_I2C1_IRQ (56 + IRQ_GIC_START) #define INT_44XX_I2C2_IRQ (57 + IRQ_GIC_START) #define INT_44XX_HDQ_IRQ (58 + IRQ_GIC_START) @@ -405,6 +406,7 @@ #define INT_44XX_MCBSP4_IRQ_TX (81 + IRQ_GIC_START) #define INT_44XX_MCBSP4_IRQ_RX (82 + IRQ_GIC_START) #define INT_44XX_MMC_IRQ (83 + IRQ_GIC_START) +#define INT_44XX_DSS_DSI2 (84 + IRQ_GIC_START) #define INT_44XX_MMC2_IRQ (86 + IRQ_GIC_START) #define INT_44XX_MCBSP2_IRQ_TX (89 + IRQ_GIC_START) #define INT_44XX_MCBSP2_IRQ_RX (90 + IRQ_GIC_START) @@ -442,7 +444,10 @@ #define INT_44XX_PARTHASH_IRQ (79 + IRQ_GIC_START) #define INT_44XX_MMC3_IRQ (94 + IRQ_GIC_START) #define INT_44XX_MMC4_IRQ (96 + IRQ_GIC_START) +#define INT_44XX_DUCATI_MMU_IRQ(100 + IRQ_GIC_START) #define INT_44XX_MCPDM_IRQ (112 + IRQ_GIC_START) +#define INT_4XX_DSS_HDMI (101 + IRQ_GIC_START) +#define INT_44XX_KBD_CTL (120 + IRQ_GIC_START) /* Max. 128 level 2 IRQs (OMAP1610), 192 GPIOs (OMAP730/850) and * 16 MPUIO lines */ -- 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] omap4: multi-omap: Allow build to work
Shilimkar, Santosh wrote: > The musb support is enable to omap3 platforms. For omap4 only board > support is available and the driver still isn't supported. > Because of this build with omap3_defconfig used for multi-omap > doesn't work on omap4430 sdp. > > This patch hacks the musb probe to keep the multi-omap build > working on omap4430 sdp > > Signed-off-by: Santosh Shilimkar > --- > drivers/usb/musb/musb_core.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/usb/musb/musb_core.c > b/drivers/usb/musb/musb_core.c > index bcce8e8..13b1c4a 100644 > --- a/drivers/usb/musb/musb_core.c > +++ b/drivers/usb/musb/musb_core.c > @@ -2124,6 +2124,10 @@ static int __init musb_probe(struct > platform_device *pdev) > struct resource *iomem; > void __iomem*base; > > + /* FIXME: multi-omap build to work on omap4 */ > + if (cpu_is_omap44xx()) > + return 0; > + NAK. I'd prefer that we fix the driver issue correctly. I would have expected the driver to at least load on OMAP4 even if it does not work. Could you please describe the failure? Also, this will need to go through linux-usb. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/24] omap4 for 2.6.34
Resending with correct patch numbers. > -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of > Shilimkar, Santosh > Sent: Tuesday, February 16, 2010 9:06 PM > To: Tony Lindgren > Cc: Ben Dooks; Samuel Ortiz; Kevin Hilman; Paul Walmsley; > l...@slimlogic.co.uk; linux- > o...@vger.kernel.org > Subject: [PATCH 0/24] omap4 for 2.6.34 > > Tony, > Here are some patches towards upcoming 34 merge window. They are generated > against > linux-omap master as you suggested. > > I am also copying Ben, Samuel, Liam, Paul and Kevin since some of the changes > are in mfd, regulator, i2c and clocks. > > The series enables most of the core driver like WDT, RTC, McBSP, Regulator, > UART,DMA and I2C on omap4 platform. This series also has few fixes towards > multi-omap build. It would be nice development platform for > upcoming peripheral drivers like MMC, Keyboard, Ethernet, DSS, touch screen, > audio etc. > > The series is boot tested with multi-omap build (omap3_defconfig) on omap3430 > sdp > and omap4430 sdp. Also regular omap_4430sdp_defconfig and > omap_3430sdp_defconfig > boot tested. > > The following changes since commit 301f2e037b161c79bf12f4194501c9ff9c12ced3: > Tony Lindgren (1): > Linux-omap rebuilt: dss board changes merged > > Abhijit Pagare (3): > omap4: clocks: Make Uart driver's clock calls OMAP4 compatible > omap4: clokcs: Make gpio driver's clock calls OMAP4 compatible > omap4: clocks: Make i2c driver's clock calls OMAP4 compatible > > Balaji T K (4): > twl6030: add base addr for ID0, ID1, ID2 > omap4: add i2c1 peripherals data > omap4: add regulator board data for TWL6030 > omap4: Enable RTC and regulator support > > Rajendra Nayak (1): > twl6030: Fix vsel calculations in set/get voltage api's > > Santosh Shilimkar (16): > omap 3/4: uart: fix full-fifo write abort > omap2/3/4: ioremap omap_globals module > omap4: sdma: Enable the idle modes on omap4 > omap: sdma: Limit the secure reserve channel fix for omap3 > omap4: Add needed IRQ line into irqs.h > omap4: Fix omap_type() for omap4 > omap 3/4: Remove overlapping mapping of L4_WKUP io space > omap4: clocks: Make mcbsp driver's clock calls OMAP4 compatible > omap4: clocks: Make watchdog driver's clock calls OMAP4 compatible > omap4: clocks: Make dmtimer clocks calls OMAP4 compatible > omap4: clocks: Remove clock hacks from timer-gp.c > omap4: Enable WDT and McBSP support > omap4: clocks: Convert i2c clocks data to fclks > omap4: Add i2c support on omap4 platform > omap4: Add i2c board support for omap4 platform > omap4: multi-omap: Allow build to work > > arch/arm/configs/omap_4430sdp_defconfig | 46 ++- > arch/arm/mach-omap2/board-4430sdp.c | 186 > + > arch/arm/mach-omap2/clock44xx_data.c |8 +- > arch/arm/mach-omap2/control.c |6 +- > arch/arm/mach-omap2/id.c |2 + > arch/arm/mach-omap2/io.c | 12 -- > arch/arm/mach-omap2/prcm.c| 16 ++- > arch/arm/mach-omap2/sdrc.c| 11 ++- > arch/arm/mach-omap2/serial.c | 55 +++-- > arch/arm/mach-omap2/timer-gp.c|5 - > arch/arm/plat-omap/common.c | 38 +++--- > arch/arm/plat-omap/dma.c |5 +- > arch/arm/plat-omap/dmtimer.c | 25 +++- > arch/arm/plat-omap/gpio.c |7 +- > arch/arm/plat-omap/i2c.c | 17 ++- > arch/arm/plat-omap/include/plat/common.h | 12 +- > arch/arm/plat-omap/include/plat/control.h |3 + > arch/arm/plat-omap/include/plat/io.h |9 -- > arch/arm/plat-omap/include/plat/irqs.h|5 + > arch/arm/plat-omap/io.c |4 - > arch/arm/plat-omap/mcbsp.c| 13 ++- > drivers/i2c/busses/i2c-omap.c | 169 -- > drivers/mfd/twl-core.c|7 +- > drivers/regulator/twl-regulator.c | 23 +++- > drivers/usb/musb/musb_core.c |4 + > drivers/watchdog/Kconfig |6 +- > drivers/watchdog/omap_wdt.c | 39 -- > include/linux/i2c/twl.h |5 + > 28 files changed, 576 insertions(+), 162 deletions(-) > > > Regards, > Santsoh > > -- > 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] omap4: add regulator board data for TWL6030
From: Balaji T K
add TWL6030 regulator board data in board-4430sdp.c
Signed-off-by: Rajendra Nayak
Signed-off-by: Balaji T K
---
arch/arm/mach-omap2/board-4430sdp.c | 161 +++
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ad0a9a5..cbdbfa4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -49,6 +50,25 @@ static struct omap_board_config_kernel sdp4430_config[]
__initdata = {
{ OMAP_TAG_LCD, &sdp4430_lcd_config },
};
+
+static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
+ {
+ .supply = "vmmc",
+ },
+ {
+ .supply = "vmmc",
+ },
+ {
+ .supply = "vmmc",
+ },
+ {
+ .supply = "vmmc",
+ },
+ {
+ .supply = "vmmc",
+ },
+};
+
static void __init gic_init_irq(void)
{
void __iomem *base;
@@ -82,9 +102,150 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
+static struct regulator_init_data sdp4430_vaux1 = {
+ .constraints = {
+ .min_uV = 100,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vaux2 = {
+ .constraints = {
+ .min_uV = 120,
+ .max_uV = 280,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vaux3 = {
+ .constraints = {
+ .min_uV = 100,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+/* VMMC1 for MMC1 card */
+static struct regulator_init_data sdp4430_vmmc = {
+ .constraints = {
+ .min_uV = 120,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 5,
+ .consumer_supplies = sdp4430_vmmc_supply,
+};
+
+static struct regulator_init_data sdp4430_vpp = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 250,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vusim = {
+ .constraints = {
+ .min_uV = 120,
+ .max_uV = 290,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vana = {
+ .constraints = {
+ .min_uV = 210,
+ .max_uV = 210,
+ .apply_uV = true,
+
[PATCH] omap4: clocks: Convert i2c clocks data to fclks
In OMAP4 I2C module has only fclk control and iclks are controlled
through hardware.(The OMAP4 clock tree autogeneration script has
been updated accordingly.)
CC:Paul Walmsley
CC:Benoit Cousson
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/clock44xx_data.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 86af31d..a69e8a0 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2665,10 +2665,10 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "gptimer9_ck", &gptimer9_ck,
CK_443X),
CLK("omap2_hdq.0", "ick", &hdq1w_ck,
CK_443X),
CLK(NULL, "hsi_ck", &hsi_ck,
CK_443X),
- CLK("i2c_omap.1", "ick", &i2c1_ck,
CK_443X),
- CLK("i2c_omap.2", "ick", &i2c2_ck,
CK_443X),
- CLK("i2c_omap.3", "ick", &i2c3_ck,
CK_443X),
- CLK("i2c_omap.4", "ick", &i2c4_ck,
CK_443X),
+ CLK("i2c_omap.1", "fck", &i2c1_ck,
CK_443X),
+ CLK("i2c_omap.2", "fck", &i2c2_ck,
CK_443X),
+ CLK("i2c_omap.3", "fck", &i2c3_ck,
CK_443X),
+ CLK("i2c_omap.4", "fck", &i2c4_ck,
CK_443X),
CLK(NULL, "iss_ck", &iss_ck,
CK_443X),
CLK(NULL, "ivahd_ck", &ivahd_ck,
CK_443X),
CLK(NULL, "keyboard_ck", &keyboard_ck,
CK_443X),
--
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] omap4: clocks: Make mcbsp driver's clock calls OMAP4 compatible
The mcbsp driver has been adapted for the OMAP4 way of clock calls.
In OMAP4, the iclk are hw controlled and no sw control is available
Signed-off-by: Abhijit Pagare
Signed-off-by: Santosh Shilimkar
---
arch/arm/plat-omap/mcbsp.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 473be3d..72b9694 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -1314,11 +1314,14 @@ static int __devinit omap_mcbsp_probe(struct
platform_device *pdev)
mcbsp->dma_rx_sync = pdata->dma_rx_sync;
mcbsp->dma_tx_sync = pdata->dma_tx_sync;
- mcbsp->iclk = clk_get(&pdev->dev, "ick");
- if (IS_ERR(mcbsp->iclk)) {
- ret = PTR_ERR(mcbsp->iclk);
- dev_err(&pdev->dev, "unable to get ick: %d\n", ret);
- goto err_iclk;
+ /* OMAP4 iclk are hw controlled and no sw control is available */
+ if (!cpu_is_omap44xx()) {
+ mcbsp->iclk = clk_get(&pdev->dev, "ick");
+ if (IS_ERR(mcbsp->iclk)) {
+ ret = PTR_ERR(mcbsp->iclk);
+ dev_err(&pdev->dev, "unable to get ick: %d\n", ret);
+ goto err_iclk;
+ }
}
mcbsp->fclk = clk_get(&pdev->dev, "fck");
--
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] omap4: clocks: Make i2c driver's clock calls OMAP4 compatible
From: Abhijit Pagare
The i2c driver has been adapted for the OMAP4 way of clock calls.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Abhijit Pagare
---
drivers/i2c/busses/i2c-omap.c | 29 -
1 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 89a156a..d4f6eda 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -260,11 +260,14 @@ static int __init omap_i2c_get_clocks(struct omap_i2c_dev
*dev)
{
int ret;
- dev->iclk = clk_get(dev->dev, "ick");
- if (IS_ERR(dev->iclk)) {
- ret = PTR_ERR(dev->iclk);
- dev->iclk = NULL;
- return ret;
+ /* OMAP4 iclk are hw controlled and no sw control is available */
+ if (!cpu_is_omap44xx()) {
+ dev->iclk = clk_get(dev->dev, "ick");
+ if (IS_ERR(dev->iclk)) {
+ ret = PTR_ERR(dev->iclk);
+ dev->iclk = NULL;
+ return ret;
+ }
}
dev->fclk = clk_get(dev->dev, "fck");
@@ -285,15 +288,18 @@ static void omap_i2c_put_clocks(struct omap_i2c_dev *dev)
{
clk_put(dev->fclk);
dev->fclk = NULL;
- clk_put(dev->iclk);
- dev->iclk = NULL;
+ if (!cpu_is_omap44xx()) {
+ clk_put(dev->iclk);
+ dev->iclk = NULL;
+ }
}
static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
WARN_ON(!dev->idle);
- clk_enable(dev->iclk);
+ if (!cpu_is_omap44xx())
+ clk_enable(dev->iclk);
clk_enable(dev->fclk);
if (cpu_is_omap34xx()) {
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
@@ -337,7 +343,8 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
}
dev->idle = 1;
clk_disable(dev->fclk);
- clk_disable(dev->iclk);
+ if (!cpu_is_omap44xx())
+ clk_disable(dev->iclk);
}
static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -434,10 +441,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
internal_clk = 9600;
else
internal_clk = 4000;
- /* FIXME: Remove this once clock framework is available*/
- if (dev->rev >= OMAP_I2C_REV_ON_4430)
- fclk_rate = 96000;
- else
fclk_rate = clk_get_rate(dev->fclk) / 1000;
/* Compute prescaler divisor */
--
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: sdma: Limit the secure reserve channel fix for omap3
The commit 'ba50ea7e' reserves DMA channels 0 and 1 on high
security devices, in order to avoid collision between kernel
dma transfers and ROM code dma transfers.
This fix is applicable only for OMAP3 so add an appropriate
check.
Signed-off-by: Santosh Shilimkar
CC: Kalle Jokiniemi
CC: Kevin Hilman
---
arch/arm/plat-omap/dma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 5ec96db..049165c 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2149,7 +2149,8 @@ static int __init omap_init_dma(void)
DMA_SYSCONFIG_AUTOIDLE);
dma_write(v , OCP_SYSCONFIG);
/* reserve dma channels 0 and 1 in high security devices */
- if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
+ if (cpu_is_omap34xx() &&
+ (omap_type() != OMAP2_DEVICE_TYPE_GP)) {
printk(KERN_INFO "Reserving DMA channels 0 and 1 for "
"HS ROM code\n");
dma_chan[0].dev_id = 0;
--
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 3/4: uart: fix full-fifo write abort
This patch is addition to the already merged commit on non-empty
uart fifo read abort. "ce13d4716a276f4331d78ba28a5093a63822ab95"
OMAP3630 and OMAP4430 UART IP blocks have a restriction on TX FIFO
too. If you try to write to the tx fifo when it is full, the system aborts.
This can be easily reproducible by not suppressing interconnect errors or
long duration testing where continuous prints over console from multiple
threads. This patch is addressing the issue by ensuring that write is
not issued while fifo is full. A timeout is added to avoid any hang
on fifo-full for 10 mS which is unlikely case.
Patch is validated on OMAP3630 and OMAP4 SDP.
V2 version removed the additional 1 uS on every TX as per
Tony's suggestion
Signed-off-by: Woodruff Richard
Signed-off-by: Santosh Shilimkar
CC: Ghorai Sukumar
---
arch/arm/mach-omap2/serial.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5f3035e..b79bc89 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -160,6 +161,13 @@ static inline unsigned int serial_read_reg(struct
plat_serial8250_port *up,
return (unsigned int)__raw_readb(up->membase + offset);
}
+static inline void __serial_write_reg(struct uart_port *up, int offset,
+ int value)
+{
+ offset <<= up->regshift;
+ __raw_writeb(value, up->membase + offset);
+}
+
static inline void serial_write_reg(struct plat_serial8250_port *p, int offset,
int value)
{
@@ -620,6 +628,20 @@ static unsigned int serial_in_override(struct uart_port
*up, int offset)
return __serial_read_reg(up, offset);
}
+static void serial_out_override(struct uart_port *up, int offset, int value)
+{
+ unsigned int status, tmout = 1;
+
+ status = __serial_read_reg(up, UART_LSR);
+ while (!(status & UART_LSR_THRE)) {
+ /* Wait up to 10ms for the character(s) to be sent. */
+ if (--tmout == 0)
+ break;
+ udelay(1);
+ status = __serial_read_reg(up, UART_LSR);
+ }
+ __serial_write_reg(up, offset, value);
+}
void __init omap_serial_early_init(void)
{
int i;
@@ -721,11 +743,14 @@ void __init omap_serial_init_port(int port)
* omap3xxx: Never read empty UART fifo on UARTs
* with IP rev >=0x52
*/
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
uart->p->serial_in = serial_in_override;
- else if ((serial_read_reg(uart->p, UART_OMAP_MVER) & 0xFF)
- >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ uart->p->serial_out = serial_out_override;
+ } else if ((serial_read_reg(uart->p, UART_OMAP_MVER) & 0xFF)
+ >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) {
uart->p->serial_in = serial_in_override;
+ uart->p->serial_out = serial_out_override;
+ }
}
/**
--
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] omap4: sdma: Enable the idle modes on omap4
This patch enables smart-idle idlemodes and autoidle for sDMA
on OMAP4
Signed-off-by: Santosh Shilimkar
---
arch/arm/plat-omap/dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 30ff525..5ec96db 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2138,7 +2138,7 @@ static int __init omap_init_dma(void)
setup_irq(irq, &omap24xx_dma_irq);
}
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
/* Enable smartidle idlemodes and autoidle */
u32 v = dma_read(OCP_SYSCONFIG);
v &= ~(DMA_SYSCONFIG_MIDLEMODE_MASK |
--
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
