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. 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. -- 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
