| Message ID | cover.54a07919b9d7fe8d7c90e9f4929648013e641cff.1522761929.git-series.maxime.ripard@bootlin.com |
|---|---|
| Headers | show |
| Series | sunxi: Add DT representation for the MBUS controller | expand |
On Tue, Apr 03, 2018 at 03:29:18PM +0200, Maxime Ripard wrote: > Now that we can express our DMA topology, rely on those property instead of > hardcoding an offset from the dma_addr_t which wasn't really great. > > We still need to add some code to deal with the old DT that would lack that > property, but we move the offset to the DRM device dma_pfn_offset to be > able to rely on just the dma_addr_t associated to the GEM object. > > Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Yay for hiding more bus address funies behind dma_map_* support. This should also help with cleaner dma-buf import. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> > --- > drivers/gpu/drm/sun4i/sun4i_backend.c | 28 +++++++++++++++++++++------- > 1 file changed, 21 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c > index 847eecbe4d14..04e85d3ca36e 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c > @@ -222,13 +222,6 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend, > paddr = drm_fb_cma_get_gem_addr(fb, state, 0); > DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr); > > - /* > - * backend DMA accesses DRAM directly, bypassing the system > - * bus. As such, the address range is different and the buffer > - * address needs to be corrected. > - */ > - paddr -= PHYS_OFFSET; > - > /* Write the 32 lower bits of the address (in bits) */ > lo_paddr = paddr << 3; > DRM_DEBUG_DRIVER("Setting address lower bits to 0x%x\n", lo_paddr); > @@ -361,6 +354,27 @@ static int sun4i_backend_bind(struct device *dev, struct device *master, > return -ENOMEM; > dev_set_drvdata(dev, backend); > > + if (of_find_property(dev->of_node, "dma-parent", NULL)) { > + /* > + * This assume we have the same DMA constraints for all our the > + * devices in our pipeline (all the backends, but also the > + * frontends). This sounds bad, but it has always been the case > + * for us, and DRM doesn't do per-device allocation either, so > + * we would need to fix DRM first... > + */ > + ret = of_dma_configure(drm->dev, dev->of_node); > + if (ret) > + return ret; > + } else { > + /* > + * If we don't have the dma-parent property, most likely > + * because of an old DT, we need to set the DMA offset by hand > + * on our device since the RAM mapping is at 0 for the DMA bus, > + * unlike the CPU. > + */ > + drm->dev->dma_pfn_offset = PHYS_PFN_OFFSET; > + } > + > backend->engine.node = dev->of_node; > backend->engine.ops = &sun4i_backend_engine_ops; > backend->engine.id = sun4i_backend_of_get_id(dev->of_node); > -- > git-series 0.9.1 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote: > Hi, > > We've had for quite some time to hack around in our drivers to take into > account the fact that our DMA accesses are not done through the parent > node, but through another bus with a different mapping than the CPU for the > RAM (0 instead of 0x40000000 for most SoCs). > > After some discussion after the submission of a camera device suffering of > the same hacks, I've decided to put together a serie that introduce a > property called dma-parent that allows to express the DMA relationship > between a master and its bus, even if they are not direct parents in the DT. Reading thru v6 of the camera driver, it seems like having intermediate buses would solve the problem in your case? As Arnd mentioned in that thread, something new needs to address all the deficiencies with dma-ranges and describing DMA bus topologies. This doesn't address the needs of describing bus interconnects. There's been some efforts by the QCom folks with an interconnect binding. They've mostly punted (for now at least) to not describing the whole interconnect in DT and keeping the details in a driver. On the flip side, this does mirror the established pattern used by interrupts, so maybe it's okay on it's own. I'll wait for others to comment. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, On Tue, Apr 03, 2018 at 11:03:30AM -0500, Rob Herring wrote: > On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > Hi, > > > > We've had for quite some time to hack around in our drivers to take into > > account the fact that our DMA accesses are not done through the parent > > node, but through another bus with a different mapping than the CPU for the > > RAM (0 instead of 0x40000000 for most SoCs). > > > > After some discussion after the submission of a camera device suffering of > > the same hacks, I've decided to put together a serie that introduce a > > property called dma-parent that allows to express the DMA relationship > > between a master and its bus, even if they are not direct parents in the DT. > > Reading thru v6 of the camera driver, it seems like having > intermediate buses would solve the problem in your case? I guess it would yes, but I guess it wouldn't model the hardware properly since this seems to be really a bus only meant to do DMA, and you're not accessing the registers of the device through that bus. And as far as I know, the DT implies that the topology is the one of the "control" side of the devices. We'll also need eventually to have retrieve the MBUS endpoints ID to be able to support perf and PM QoS properly. > As Arnd mentioned in that thread, something new needs to address all > the deficiencies with dma-ranges and describing DMA bus topologies. > This doesn't address the needs of describing bus interconnects. > There's been some efforts by the QCom folks with an interconnect > binding. They've mostly punted (for now at least) to not describing > the whole interconnect in DT and keeping the details in a driver. Is it that patch serie? https://lkml.org/lkml/2018/3/9/856 > On the flip side, this does mirror the established pattern used by > interrupts, so maybe it's okay on it's own. I'll wait for others to > comment. We'll see how it turns out then :) Maxime
On Mon, Apr 09, 2018 at 11:22:29AM +0200, Maxime Ripard wrote: > Hi Rob, > > On Tue, Apr 03, 2018 at 11:03:30AM -0500, Rob Herring wrote: > > On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > Hi, > > > > > > We've had for quite some time to hack around in our drivers to take into > > > account the fact that our DMA accesses are not done through the parent > > > node, but through another bus with a different mapping than the CPU for the > > > RAM (0 instead of 0x40000000 for most SoCs). > > > > > > After some discussion after the submission of a camera device suffering of > > > the same hacks, I've decided to put together a serie that introduce a > > > property called dma-parent that allows to express the DMA relationship > > > between a master and its bus, even if they are not direct parents in the DT. > > > > Reading thru v6 of the camera driver, it seems like having > > intermediate buses would solve the problem in your case? > > I guess it would yes, but I guess it wouldn't model the hardware > properly since this seems to be really a bus only meant to do DMA, and > you're not accessing the registers of the device through that bus. > > And as far as I know, the DT implies that the topology is the one of > the "control" side of the devices. > > We'll also need eventually to have retrieve the MBUS endpoints ID to > be able to support perf and PM QoS properly. > > > As Arnd mentioned in that thread, something new needs to address all > > the deficiencies with dma-ranges and describing DMA bus topologies. > > This doesn't address the needs of describing bus interconnects. > > There's been some efforts by the QCom folks with an interconnect > > binding. They've mostly punted (for now at least) to not describing > > the whole interconnect in DT and keeping the details in a driver. > > Is it that patch serie? https://lkml.org/lkml/2018/3/9/856 > > > On the flip side, this does mirror the established pattern used by > > interrupts, so maybe it's okay on it's own. I'll wait for others to > > comment. > > We'll see how it turns out then :) Ping? How should we move forward on this? Maxime