Re: [alsa-devel] [PATCH v2 08/13] OMAP2+: McBSP: hwmod adaptation for McBSP
On Thu, 17 Feb 2011 15:41:40 -0800 Tony Lindgren t...@atomide.com wrote: Actually this part of code doesn't compile for CONFIG_ARCH_OMAP2 if CONFIG_ARCH_OMAP3 is not set. Reason is that the buffer_size in under CONFIG_ARCH_OMAP3 compilation in struct omap_mcbsp_platform_data definition. I think it's easiest if this patch just removes that conditional compilation from struct omap_mcbsp_platform_data as it really doesn't save that much from non !OMAP3 builds. Thanks. Will fix it in the next version. Any news on updating this series? Note that you can now leave out the omap4 hwmod data as that has been merged to omap-for-linus. My impression from last round was that there is not that many changes required. Of course there must not have bisect issues like above, should not break OMAP1 (which I think was addressed already) but otherwise I think most of the issues were small. Kevin had concerns about PM testing but I would not put that much emphasis on that since the set should not make things any worse but should make possible to go forward with PM. -- 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: [alsa-devel] [PATCH v2 08/13] OMAP2+: McBSP: hwmod adaptation for McBSP
Hi, I'll send patch series in a short while. -Kishon On Fri, Feb 18, 2011 at 1:38 PM, Jarkko Nikula jhnik...@gmail.com wrote: On Thu, 17 Feb 2011 15:41:40 -0800 Tony Lindgren t...@atomide.com wrote: Actually this part of code doesn't compile for CONFIG_ARCH_OMAP2 if CONFIG_ARCH_OMAP3 is not set. Reason is that the buffer_size in under CONFIG_ARCH_OMAP3 compilation in struct omap_mcbsp_platform_data definition. I think it's easiest if this patch just removes that conditional compilation from struct omap_mcbsp_platform_data as it really doesn't save that much from non !OMAP3 builds. Thanks. Will fix it in the next version. Any news on updating this series? Note that you can now leave out the omap4 hwmod data as that has been merged to omap-for-linus. My impression from last round was that there is not that many changes required. Of course there must not have bisect issues like above, should not break OMAP1 (which I think was addressed already) but otherwise I think most of the issues were small. Kevin had concerns about PM testing but I would not put that much emphasis on that since the set should not make things any worse but should make possible to go forward with PM. -- 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: [alsa-devel] [PATCH v2 08/13] OMAP2+: McBSP: hwmod adaptation for McBSP
* ABRAHAM, KISHON VIJAY kis...@ti.com [110201 22:22]:
On Tue, Feb 1, 2011 at 11:14 PM, Jarkko Nikula jhnik...@gmail.com wrote:
On Tue, 01 Feb 2011 14:22:49 +0200
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
Looks good, but...
+ if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
+ if (id == 2)
+ pdata-buffer_size = 0x500; /*FIFO size is 1024 +
256*/
+ else
+ pdata-buffer_size = 0x80; /*FIFO size is 128*/
+ }
I would add spaces around these comments (after /* and before */).
Actually this part of code doesn't compile for CONFIG_ARCH_OMAP2 if
CONFIG_ARCH_OMAP3 is not set. Reason is that the buffer_size in under
CONFIG_ARCH_OMAP3 compilation in struct omap_mcbsp_platform_data
definition.
I think it's easiest if this patch just removes that conditional
compilation from struct omap_mcbsp_platform_data as it really doesn't
save that much from non !OMAP3 builds.
Thanks. Will fix it in the next version.
Any news on updating this series?
Note that you can now leave out the omap4 hwmod data as that has
been merged to omap-for-linus.
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] OMAP2+: McBSP: hwmod adaptation for McBSP
Looks good, but...
On 01/31/2011 04:50 PM, ext Kishon Vijay Abraham I wrote:
Modify OMAP2+ McBSP to use omap hwmod framework APIs
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/mcbsp.c | 685
+++
1 files changed, 43 insertions(+), 642 deletions(-)
...
+ if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
+ if (id == 2)
+ pdata-buffer_size = 0x500; /*FIFO size is 1024 + 256*/
+ else
+ pdata-buffer_size = 0x80; /*FIFO size is 128*/
+ }
I would add spaces around these comments (after /* and before */).
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v2 08/13] OMAP2+: McBSP: hwmod adaptation for McBSP
On Tue, Feb 1, 2011 at 11:14 PM, Jarkko Nikula jhnik...@gmail.com wrote:
On Tue, 01 Feb 2011 14:22:49 +0200
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
Looks good, but...
+ if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
+ if (id == 2)
+ pdata-buffer_size = 0x500; /*FIFO size is 1024 + 256*/
+ else
+ pdata-buffer_size = 0x80; /*FIFO size is 128*/
+ }
I would add spaces around these comments (after /* and before */).
Actually this part of code doesn't compile for CONFIG_ARCH_OMAP2 if
CONFIG_ARCH_OMAP3 is not set. Reason is that the buffer_size in under
CONFIG_ARCH_OMAP3 compilation in struct omap_mcbsp_platform_data
definition.
I think it's easiest if this patch just removes that conditional
compilation from struct omap_mcbsp_platform_data as it really doesn't
save that much from non !OMAP3 builds.
Thanks. Will fix it in the next version.
--
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
[PATCH v2 08/13] OMAP2+: McBSP: hwmod adaptation for McBSP
Modify OMAP2+ McBSP to use omap hwmod framework APIs
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/mcbsp.c | 685 +++
1 files changed, 43 insertions(+), 642 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index bc004be..7d0fe2b 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -22,10 +22,10 @@
#include plat/dma.h
#include plat/cpu.h
#include plat/mcbsp.h
+#include plat/omap_device.h
#include control.h
-
/* McBSP internal signal muxing functions */
void omap2_mcbsp1_mux_clkr_src(u8 mux)
@@ -101,664 +101,65 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
}
EXPORT_SYMBOL(omap2_mcbsp_set_clks_src);
-
-/* Platform data */
-
-#ifdef CONFIG_SOC_OMAP2420
-struct resource omap2420_mcbsp_res[][6] = {
- {
- {
- .name = mpu,
- .start = OMAP24XX_MCBSP1_BASE,
- .end = OMAP24XX_MCBSP1_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = dma,
- .start = OMAP24XX_MCBSP1_BASE,
- .end = OMAP24XX_MCBSP1_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = rx,
- .start = INT_24XX_MCBSP1_IRQ_RX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = tx,
- .start = INT_24XX_MCBSP1_IRQ_TX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = rx,
- .start = OMAP24XX_DMA_MCBSP1_RX,
- .flags = IORESOURCE_DMA,
- },
- {
- .name = tx,
- .start = OMAP24XX_DMA_MCBSP1_TX,
- .flags = IORESOURCE_DMA,
- },
- },
+struct omap_device_pm_latency omap2_mcbsp_latency[] = {
{
- {
- .name = mpu,
- .start = OMAP24XX_MCBSP2_BASE,
- .end = OMAP24XX_MCBSP2_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = dma,
- .start = OMAP24XX_MCBSP2_BASE,
- .end = OMAP24XX_MCBSP2_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = rx,
- .start = INT_24XX_MCBSP2_IRQ_RX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = tx,
- .start = INT_24XX_MCBSP2_IRQ_TX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = rx,
- .start = OMAP24XX_DMA_MCBSP2_RX,
- .flags = IORESOURCE_DMA,
- },
- {
- .name = tx,
- .start = OMAP24XX_DMA_MCBSP2_TX,
- .flags = IORESOURCE_DMA,
- },
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
},
};
-#define OMAP2420_MCBSP_RES_SZ ARRAY_SIZE(omap2420_mcbsp_res[1])
-#define OMAP2420_MCBSP_COUNT ARRAY_SIZE(omap2420_mcbsp_res)
-#else
-#define omap2420_mcbsp_res NULL
-#define OMAP2420_MCBSP_RES_SZ 0
-#define OMAP2420_MCBSP_COUNT 0
-#endif
+static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
+{
+ int id, count = 1;
+ char *name = omap-mcbsp;
+ struct omap_hwmod *oh_device[2];
+ struct omap_mcbsp_platform_data *pdata = NULL;
+ struct omap_device *od;
-#define omap2420_mcbsp_pdata NULL
+ sscanf(oh-name, mcbsp%d, id);
-#ifdef CONFIG_SOC_OMAP2430
-struct resource omap2430_mcbsp_res[][6] = {
- {
- {
- .name = mpu,
- .start = OMAP24XX_MCBSP1_BASE,
- .end = OMAP24XX_MCBSP1_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = dma,
- .start = OMAP24XX_MCBSP1_BASE,
- .end = OMAP24XX_MCBSP1_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = rx,
- .start = INT_24XX_MCBSP1_IRQ_RX,
- .flags =
