On Wednesday 06 October 2010 09:12:34 ext Varadarajan, Charulatha wrote:
> This patch series would not break OMAP1 as they do not touch
> the omap_mcbsp_register_board_cfg() in mach-omap1.
But the plat-omap/mcbsp will not going to be able to prope on OMAP1, or did I
missed something?
Snip:
@@ -1775,25 +1685,50 @@ static int __devinit omap_mcbsp_probe(struct
platform_device *pdev)
mcbsp->dma_tx_lch = -1;
mcbsp->dma_rx_lch = -1;
- mcbsp->phys_base = pdata->phys_base;
- mcbsp->io_base = ioremap(pdata->phys_base, SZ_4K);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "%s:mcbsp%d has invalid memory resource\n",
+ __func__, pdev->id);
+ ret = -ENOMEM;
+ goto exit;
+ }
+ mcbsp->phys_base = res->start;
+ mcbsp->io_base = ioremap(res->start, resource_size(res));
if (!mcbsp->io_base) {
ret = -ENOMEM;
goto err_ioremap;
}
+ omap_mcbsp_cache_size = resource_size(res);
+
/* Default I/O is IRQ based */
mcbsp->io_type = OMAP_MCBSP_IRQ_IO;
- mcbsp->tx_irq = pdata->tx_irq;
- mcbsp->rx_irq = pdata->rx_irq;
- mcbsp->dma_rx_sync = pdata->dma_rx_sync;
- mcbsp->dma_tx_sync = pdata->dma_tx_sync;
+ mcbsp->tx_irq = platform_get_irq_byname(pdev, "tx");
+ mcbsp->rx_irq = platform_get_irq_byname(pdev, "rx");
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
+ if (!res) {
+ dev_err(&pdev->dev, "%s:mcbsp%d has invalid DMA channel\n",
+ __func__, pdev->id);
+ ret = -ENODEV;
+ goto err_res;
+ }
+ mcbsp->dma_rx_sync = res->start;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
+ if (!res) {
+ dev_err(&pdev->dev, "%s:mcbsp%d has invalid DMA channel\n",
+ __func__, pdev->id);
+ ret = -ENODEV;
+ goto err_res;
+ }
+ mcbsp->dma_tx_sync = res->start;
I don't think that on OMAP1 the platform_get_resource_byname function will find
the needed resources...
>
> Usage of hwmod is applicable only for OMAP2plus cpus and it modifies
> the way in which the platform device is built & registered. It makes
> use of centralised database to fetch the addresses, irq, dma info etc.,
> for OMAP2plus. OMAP1 cpus will still continue to have the old way of
> doing platform device registeration.
>
> pm_runtime APIs are already inplace to take care of enabling clocks in
> case of OMAP1.
>
> Hope this clarifies.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
