| Message ID | E1VMnNq-0007s4-HN@rmk-PC.arm.linux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: > The correct way for a driver to specify the coherent DMA mask is > not to directly access the field in the struct device, but to use > dma_set_coherent_mask(). Only arch and bus code should access this > member directly. > > Convert all direct write accesses to using the correct API. > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Tejun Heo <tj@kernel.org> The patch is pretty widely spread. I don't mind how it gets routed but what's the plan? Thanks.
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote: > On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: > > The correct way for a driver to specify the coherent DMA mask is > > not to directly access the field in the struct device, but to use > > dma_set_coherent_mask(). Only arch and bus code should access this > > member directly. > > > > Convert all direct write accesses to using the correct API. > > > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> > > Acked-by: Tejun Heo <tj@kernel.org> > > The patch is pretty widely spread. I don't mind how it gets routed > but what's the plan? Hmm... maybe hte pata_ixp4xx_cf.c part should be moved to the one which updates pata_octeon_cf.c? Thanks.
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote: > On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: > > The correct way for a driver to specify the coherent DMA mask is > > not to directly access the field in the struct device, but to use > > dma_set_coherent_mask(). Only arch and bus code should access this > > member directly. > > > > Convert all direct write accesses to using the correct API. > > > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> > > Acked-by: Tejun Heo <tj@kernel.org> > > The patch is pretty widely spread. I don't mind how it gets routed > but what's the plan? The plan is... I'm going to try and avoid going through the hell of re-posting this patch series to all the recipients another time... (It's taken some 17 hours and lots of hand holding to get this patch set out without exim jumping off a cliff into deep OOM - soo deep that even the OOM killer doesn't run and the CPU is 100% idle because every single process stuck in an uninterruptible sleep waiting for every other process to free some memory - ouch!) I know that dealing with this patch set will be a problem due to how widespread this is, but much of the driver level changes come down to depending on a couple of patches. One solution would be if I published a branch with just the dependencies in, which subsystem maintainers could pull, and then apply the appropriate patches on top. Another would be if subsystem maintainers are happy that I carry them, I can add the acks, and then later on towards the end of the cycle, provide a branch subsystem maintainers could pull. Or... if you can think of something easier... -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hey, On Fri, Sep 20, 2013 at 03:00:18PM +0100, Russell King - ARM Linux wrote: > Another would be if subsystem maintainers are happy that I carry them, > I can add the acks, and then later on towards the end of the cycle, > provide a branch subsystem maintainers could pull. > > Or... if you can think of something easier... I'm happy with the latter method and it's likely that you'll end up carrying at least some of the patches through your tree anyway. Please feel free to add my acks to all libata related patches and carry them through your tree. Thanks and have fun routing.
Hi, On Friday 20 September 2013 04:41 AM, Russell King wrote: > The correct way for a driver to specify the coherent DMA mask is > not to directly access the field in the struct device, but to use > dma_set_coherent_mask(). Only arch and bus code should access this > member directly. > > Convert all direct write accesses to using the correct API. > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> > --- > drivers/ata/pata_ixp4xx_cf.c | 5 ++++- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +++++- > drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +++-- > 3 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c > index 1ec53f8..ddf470c 100644 > --- a/drivers/ata/pata_ixp4xx_cf.c > +++ b/drivers/ata/pata_ixp4xx_cf.c > @@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device *pdev) > struct ata_host *host; > struct ata_port *ap; > struct ixp4xx_pata_data *data = dev_get_platdata(&pdev->dev); > + int ret; > > cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0); > cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1); > @@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device *pdev) > return -ENOMEM; > > /* acquire resources and fill host */ > - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > + ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); > + if (ret) > + return ret; > > data->cs0 = devm_ioremap(&pdev->dev, cs0->start, 0x1000); > data->cs1 = devm_ioremap(&pdev->dev, cs1->start, 0x1000); > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c > index bb82ef7..81192d0 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > @@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = { > > static int exynos_drm_platform_probe(struct platform_device *pdev) > { > - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > + int ret; > + > + ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); > + if (ret) > + return ret; > > return drm_platform_init(&exynos_drm_driver, pdev); > } > diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c > index acf6678..701c4c1 100644 > --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c > +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c > @@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev) > } > > /* set dma mask for device */ > - /* NOTE: this is a workaround for the hwmod not initializing properly */ > - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > + ret = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32)); > + if (ret) > + goto fail; Tested with omapdrm on omap4 panda es board. Thanks, Archit -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c index 1ec53f8..ddf470c 100644 --- a/drivers/ata/pata_ixp4xx_cf.c +++ b/drivers/ata/pata_ixp4xx_cf.c @@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device *pdev) struct ata_host *host; struct ata_port *ap; struct ixp4xx_pata_data *data = dev_get_platdata(&pdev->dev); + int ret; cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0); cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1); @@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device *pdev) return -ENOMEM; /* acquire resources and fill host */ - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); + ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); + if (ret) + return ret; data->cs0 = devm_ioremap(&pdev->dev, cs0->start, 0x1000); data->cs1 = devm_ioremap(&pdev->dev, cs1->start, 0x1000); diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index bb82ef7..81192d0 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = { static int exynos_drm_platform_probe(struct platform_device *pdev) { - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); + int ret; + + ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); + if (ret) + return ret; return drm_platform_init(&exynos_drm_driver, pdev); } diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c index acf6678..701c4c1 100644 --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c @@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev) } /* set dma mask for device */ - /* NOTE: this is a workaround for the hwmod not initializing properly */ - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); + ret = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32)); + if (ret) + goto fail; omap_dmm->dummy_pa = page_to_phys(omap_dmm->dummy_page);
The correct way for a driver to specify the coherent DMA mask is not to directly access the field in the struct device, but to use dma_set_coherent_mask(). Only arch and bus code should access this member directly. Convert all direct write accesses to using the correct API. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> --- drivers/ata/pata_ixp4xx_cf.c | 5 ++++- drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +++++- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +++-- 3 files changed, 12 insertions(+), 4 deletions(-)