| Message ID | 20090512095745.25477.87326.sendpatchset@rx1.opensource.se (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
On Tue, May 12, 2009 at 06:57:45PM +0900, Magnus Damm wrote: > From: Magnus Damm <damm@igel.co.jp> > > This patch adds memory resource support to the LCDC driver. > With this applied the physical memory range used for framebuffer > data will show up in /proc/iomem together with other SuperH > Mobile devices. > > Signed-off-by: Magnus Damm <damm@igel.co.jp> Drivers have no place doing this on their own, besides, insert_resource() is not available to modules. The platform device code already takes care of this, so perhaps I am missing what the point of this change is? -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 12, 2009 at 7:50 PM, Paul Mundt <lethal@linux-sh.org> wrote: > On Tue, May 12, 2009 at 06:57:45PM +0900, Magnus Damm wrote: >> From: Magnus Damm <damm@igel.co.jp> >> >> This patch adds memory resource support to the LCDC driver. >> With this applied the physical memory range used for framebuffer >> data will show up in /proc/iomem together with other SuperH >> Mobile devices. >> >> Signed-off-by: Magnus Damm <damm@igel.co.jp> > > Drivers have no place doing this on their own, besides, insert_resource() > is not available to modules. The platform device code already takes care > of this, so perhaps I am missing what the point of this change is? Other SuperH Mobile multimedia blocks like the CEU and VEU/VPU/JPU all get passed a physically contiguous area of memory as platform data. So for those blocks the memory range show up in /proc/iomem. For the LCDC this does not happen today. Thanks for pointing out the module issue. I guess the proper fix would be to pass a struct resource with memory to the LCDC driver as well instead of this patch. Cheeers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- 0001/drivers/video/sh_mobile_lcdcfb.c +++ work/drivers/video/sh_mobile_lcdcfb.c 2009-05-11 21:14:35.000000000 +0900 @@ -35,6 +35,7 @@ struct sh_mobile_lcdc_chan { struct fb_deferred_io defio; unsigned long frame_end; wait_queue_head_t frame_end_wait; + struct resource memory; }; struct sh_mobile_lcdc_priv { @@ -813,12 +814,26 @@ static int __init sh_mobile_lcdc_probe(s break; } + res = &priv->ch[i].memory; + res->name = "lcdc"; + res->start = priv->ch[i].dma_handle; + res->end = res->start + info->fix.smem_len - 1; + res->flags = IORESOURCE_MEM | IORESOURCE_BUSY; + error = insert_resource(&iomem_resource, res); + if (error) { + dev_err(&pdev->dev, "unable to request resource\n"); + dma_free_coherent(&pdev->dev, info->fix.smem_len, + buf, priv->ch[i].dma_handle); + break; + } + info->pseudo_palette = &priv->ch[i].pseudo_palette; info->flags = FBINFO_FLAG_DEFAULT; error = fb_alloc_cmap(&info->cmap, PALETTE_NR, 0); if (error < 0) { dev_err(&pdev->dev, "unable to allocate cmap\n"); + release_resource(res); dma_free_coherent(&pdev->dev, info->fix.smem_len, buf, priv->ch[i].dma_handle); break; @@ -887,6 +902,7 @@ static int sh_mobile_lcdc_remove(struct if (!info->device) continue; + release_resource(&priv->ch[i].memory); dma_free_coherent(&pdev->dev, info->fix.smem_len, info->screen_base, priv->ch[i].dma_handle); fb_dealloc_cmap(&info->cmap);