* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [120418 12:14]: > On Wed, Apr 18, 2012 at 11:19:18AM -0700, Tony Lindgren wrote: > > * T Krishnamoorthy, Balaji <balajitk@xxxxxx> [120418 08:39]: > > > On Wed, Apr 18, 2012 at 8:59 PM, Russell King - ARM Linux > > > <linux@xxxxxxxxxxxxxxxx> wrote: > > > > On Wed, Apr 18, 2012 at 08:53:32PM +0530, T Krishnamoorthy, Balaji wrote: > > > >> Hi, > > > >> > > > >> drivers/mmc/host/omap.c is also using dma_mask should that also be removed > > > > > > > > Does this driver make use of this platform data? > > > > > > > > If so, it needs converting to DMA engine _before_ this patch (which is > > > > one reason why its a good idea to do these changes as separate patches... > > > > as I've done.) It means stuff like this can be slotted in as necessary > > > > in the patch order. > > > > Can't we can just do this in drivers/mmc/host/omap.c: > > > > - host->dev->dma_mask = &pdata->dma_mask; > > + host->dev->dma_mask = 0xffffffff; > > > > And that way drop it from the platform data. Looks like some omap1 > > omap_mmc_platform_data don't have it set though, but we do have host->use_dma = 1 > > set anyways in drivers/mmc/host/omap.c. > > No. dma_mask is a pointer to u64. You need it stored in some variable. Oops yeah. > But, really, we shouldn't be initializing dma masks in drivers at all. > That's supposed to come from the point where devices are created - and > in the case of DMA engine stuff, its not the peripheral device structures > which are doing DMA (they're DMA-incapable) - they rely on the services > of a separate IP to perform DMA on their behalf. OK Tony -- 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
