Message ID | 1458207563-3453369-1-git-send-email-arnd@arndb.de (mailing list archive) |
---|---|
State | Accepted |
Commit | defb893fffef89ac6db4e68fccae1783d7c93977 |
Delegated to: | Kalle Valo |
Headers | show |
Arnd Bergmann <arnd@arndb.de> writes: > While fixing another bug, I noticed that bcma manually sets up > a dma_mask pointer for its child devices. We have a generic > helper for that now, which should be able to cope better with > any variations that might be needed to deal with cache coherency, > unusual DMA address offsets, iommus, or limited DMA masks, none > of which are currently handled here. > > This changes the core to use the of_dma_configure(), like > we do for platform devices that are probed directly from > DT. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > This patch needs to be tested to ensure we don't introduce > regressions, and should probably go into 4.7 as a cleanup. Is anyone able to test this? The full patch is here: https://patchwork.kernel.org/patch/8608751/
Arnd Bergmann <arnd@arndb.de> wrote: > While fixing another bug, I noticed that bcma manually sets up > a dma_mask pointer for its child devices. We have a generic > helper for that now, which should be able to cope better with > any variations that might be needed to deal with cache coherency, > unusual DMA address offsets, iommus, or limited DMA masks, none > of which are currently handled here. > > This changes the core to use the of_dma_configure(), like > we do for platform devices that are probed directly from > DT. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Nobody tested this, so I'll drop the patch.
On 17 March 2016 at 10:39, Arnd Bergmann <arnd@arndb.de> wrote: > While fixing another bug, I noticed that bcma manually sets up > a dma_mask pointer for its child devices. We have a generic > helper for that now, which should be able to cope better with > any variations that might be needed to deal with cache coherency, > unusual DMA address offsets, iommus, or limited DMA masks, none > of which are currently handled here. > > This changes the core to use the of_dma_configure(), like > we do for platform devices that are probed directly from > DT. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> I applied this patch and tested on BCM47081 based device. I still got bgmac working which surely uses DMA. There is only 1 ARM wireless SoC using bcma (BCM47198) but its WiFi core isn't supported by b43. Any tips what else to test? SPI core/driver doesn't use DMA. Maybe NAND core does, but we don't use it.
On Monday, September 5, 2016 11:34:14 PM CEST Rafał Miłecki wrote: > On 17 March 2016 at 10:39, Arnd Bergmann <arnd@arndb.de> wrote: > > While fixing another bug, I noticed that bcma manually sets up > > a dma_mask pointer for its child devices. We have a generic > > helper for that now, which should be able to cope better with > > any variations that might be needed to deal with cache coherency, > > unusual DMA address offsets, iommus, or limited DMA masks, none > > of which are currently handled here. > > > > This changes the core to use the of_dma_configure(), like > > we do for platform devices that are probed directly from > > DT. > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > I applied this patch and tested on BCM47081 based device. I still got > bgmac working which surely uses DMA. Thanks! > There is only 1 ARM wireless SoC > using bcma (BCM47198) but its WiFi core isn't supported by b43. > > Any tips what else to test? SPI core/driver doesn't use DMA. Maybe > NAND core does, but we don't use it. > If there is nothing else using this, then the patch won't cause a regression ;-) Arnd
Arnd Bergmann <arnd@arndb.de> wrote: > While fixing another bug, I noticed that bcma manually sets up > a dma_mask pointer for its child devices. We have a generic > helper for that now, which should be able to cope better with > any variations that might be needed to deal with cache coherency, > unusual DMA address offsets, iommus, or limited DMA masks, none > of which are currently handled here. > > This changes the core to use the of_dma_configure(), like > we do for platform devices that are probed directly from > DT. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Thanks, 1 patch applied to wireless-drivers-next.git: defb893fffef bcma: use of_dma_configure() to set initial dma mask
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c index 1f635471f318..2c1798e38abd 100644 --- a/drivers/bcma/main.c +++ b/drivers/bcma/main.c @@ -209,6 +209,8 @@ static void bcma_of_fill_device(struct platform_device *parent, core->dev.of_node = node; core->irq = bcma_of_get_irq(parent, core, 0); + + of_dma_configure(&core->dev, node); } unsigned int bcma_core_irq(struct bcma_device *core, int num) @@ -248,12 +250,12 @@ void bcma_prepare_core(struct bcma_bus *bus, struct bcma_device *core) core->irq = bus->host_pci->irq; break; case BCMA_HOSTTYPE_SOC: - core->dev.dma_mask = &core->dev.coherent_dma_mask; - if (bus->host_pdev) { + if (IS_ENABLED(CONFIG_OF) && bus->host_pdev) { core->dma_dev = &bus->host_pdev->dev; core->dev.parent = &bus->host_pdev->dev; bcma_of_fill_device(bus->host_pdev, core); } else { + core->dev.dma_mask = &core->dev.coherent_dma_mask; core->dma_dev = &core->dev; } break;
While fixing another bug, I noticed that bcma manually sets up a dma_mask pointer for its child devices. We have a generic helper for that now, which should be able to cope better with any variations that might be needed to deal with cache coherency, unusual DMA address offsets, iommus, or limited DMA masks, none of which are currently handled here. This changes the core to use the of_dma_configure(), like we do for platform devices that are probed directly from DT. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- This patch needs to be tested to ensure we don't introduce regressions, and should probably go into 4.7 as a cleanup. v2: fix typo drivers/bcma/main.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)