Hi,
Here's an attempt to removing the dma_direct_set_offset calls we have in
numerous drivers and move all those quirks into a global notifier as suggested
by Robin.
Let me know what you think,
Maxime
Maxime Ripard (7):
drm/sun4i: backend: Fix probe failure with multiple backends
soc: sunxi: Deal with the MBUS DMA offsets in a central place
drm/sun4i: backend: Remove the MBUS quirks
media: sun4i: Remove the MBUS quirks
media: sun6i: Remove the MBUS quirks
media: cedrus: Remove the MBUS quirks
media: sun8i-di: Remove the call to of_dma_configure
drivers/gpu/drm/sun4i/sun4i_backend.c | 13 --
.../platform/sunxi/sun4i-csi/sun4i_csi.c | 27 ----
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 17 ---
.../media/platform/sunxi/sun8i-di/sun8i-di.c | 4 -
drivers/soc/sunxi/Kconfig | 8 ++
drivers/soc/sunxi/Makefile | 1 +
drivers/soc/sunxi/sunxi_mbus.c | 132 ++++++++++++++++++
drivers/staging/media/sunxi/cedrus/cedrus.c | 1 -
drivers/staging/media/sunxi/cedrus/cedrus.h | 3 -
.../staging/media/sunxi/cedrus/cedrus_hw.c | 18 ---
10 files changed, 141 insertions(+), 83 deletions(-)
create mode 100644 drivers/soc/sunxi/sunxi_mbus.c
--
2.28.0
Hi,
On Fri, Nov 6, 2020 at 11:15 PM Maxime Ripard <[email protected]> wrote:
>
> Hi,
>
> Here's an attempt to removing the dma_direct_set_offset calls we have in
> numerous drivers and move all those quirks into a global notifier as suggested
> by Robin.
>
> Let me know what you think,
> Maxime
>
> Maxime Ripard (7):
> drm/sun4i: backend: Fix probe failure with multiple backends
> soc: sunxi: Deal with the MBUS DMA offsets in a central place
> drm/sun4i: backend: Remove the MBUS quirks
> media: sun4i: Remove the MBUS quirks
> media: sun6i: Remove the MBUS quirks
> media: cedrus: Remove the MBUS quirks
> media: sun8i-di: Remove the call to of_dma_configure
Whole series looks good to me.
Reviewed-by: Chen-Yu Tsai <[email protected]>
Now the question remaining is how do we merge this series so that
the notifier gets merged before all the code dealing with the MBUS
quirk gets removed.
> drivers/gpu/drm/sun4i/sun4i_backend.c | 13 --
> .../platform/sunxi/sun4i-csi/sun4i_csi.c | 27 ----
> .../platform/sunxi/sun6i-csi/sun6i_csi.c | 17 ---
> .../media/platform/sunxi/sun8i-di/sun8i-di.c | 4 -
> drivers/soc/sunxi/Kconfig | 8 ++
> drivers/soc/sunxi/Makefile | 1 +
> drivers/soc/sunxi/sunxi_mbus.c | 132 ++++++++++++++++++
> drivers/staging/media/sunxi/cedrus/cedrus.c | 1 -
> drivers/staging/media/sunxi/cedrus/cedrus.h | 3 -
> .../staging/media/sunxi/cedrus/cedrus_hw.c | 18 ---
> 10 files changed, 141 insertions(+), 83 deletions(-)
> create mode 100644 drivers/soc/sunxi/sunxi_mbus.c
>
> --
> 2.28.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Thanks,
this looks good to me:
Reviewed-by: Christoph Hellwig <[email protected]>
Can you include this patch at the end of your series to that it gets
picked up with the other patches?
---
From 5963f88d365367fe74d477b8420d34562d684406 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <[email protected]>
Date: Fri, 6 Nov 2020 17:02:17 +0100
Subject: dma-mapping: remove the dma_direct_set_offset export
Drop the dma_direct_set_offset export and move the declaration to
dma-map-ops.h now that the Allwinner drivers have stopped calling it.
Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/arm/mach-keystone/keystone.c | 2 +-
arch/arm/mach-omap1/usb.c | 2 +-
arch/sh/drivers/pci/pcie-sh7786.c | 2 +-
arch/x86/pci/sta2x11-fixup.c | 3 ++-
include/linux/dma-map-ops.h | 3 +++
include/linux/dma-mapping.h | 7 -------
kernel/dma/direct.c | 1 -
7 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index 09a65c2dfd7327..cd711bfc591f21 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -8,7 +8,7 @@
*/
#include <linux/io.h>
#include <linux/of.h>
-#include <linux/dma-mapping.h>
+#include <linux/dma-map-ops.h>
#include <linux/init.h>
#include <linux/of_platform.h>
#include <linux/of_address.h>
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index ba8566204ea9f4..86d3b3c157af44 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -9,7 +9,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
-#include <linux/dma-mapping.h>
+#include <linux/dma-map-ops.h>
#include <linux/io.h>
#include <asm/irq.h>
diff --git a/arch/sh/drivers/pci/pcie-sh7786.c b/arch/sh/drivers/pci/pcie-sh7786.c
index 4468289ab2cac7..4d499476c33ad6 100644
--- a/arch/sh/drivers/pci/pcie-sh7786.c
+++ b/arch/sh/drivers/pci/pcie-sh7786.c
@@ -12,7 +12,7 @@
#include <linux/io.h>
#include <linux/async.h>
#include <linux/delay.h>
-#include <linux/dma-mapping.h>
+#include <linux/dma-map-ops.h>
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/sh_clk.h>
diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
index 5701d5ba3df4ba..7d25256918543f 100644
--- a/arch/x86/pci/sta2x11-fixup.c
+++ b/arch/x86/pci/sta2x11-fixup.c
@@ -11,7 +11,8 @@
#include <linux/pci_ids.h>
#include <linux/export.h>
#include <linux/list.h>
-#include <linux/dma-direct.h>
+#include <linux/dma-map-ops.h>
+#include <linux/swiotlb.h>
#include <asm/iommu.h>
#define STA2X11_SWIOTLB_SIZE (4*1024*1024)
diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
index a5f89fc4d6df16..03925e438ec3e5 100644
--- a/include/linux/dma-map-ops.h
+++ b/include/linux/dma-map-ops.h
@@ -226,6 +226,9 @@ struct page *dma_alloc_from_pool(struct device *dev, size_t size,
bool (*phys_addr_ok)(struct device *, phys_addr_t, size_t));
bool dma_free_from_pool(struct device *dev, void *start, size_t size);
+int dma_direct_set_offset(struct device *dev, phys_addr_t cpu_start,
+ dma_addr_t dma_start, u64 size);
+
#ifdef CONFIG_ARCH_HAS_DMA_COHERENCE_H
#include <asm/dma-coherence.h>
#elif defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2aaed35b556df4..2e49996a8f391a 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -558,11 +558,4 @@ static inline int dma_mmap_wc(struct device *dev,
#define dma_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0)
#endif
-/*
- * Legacy interface to set up the dma offset map. Drivers really should not
- * actually use it, but we have a few legacy cases left.
- */
-int dma_direct_set_offset(struct device *dev, phys_addr_t cpu_start,
- dma_addr_t dma_start, u64 size);
-
#endif /* _LINUX_DMA_MAPPING_H */
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 06c111544f61d6..002268262c9ad8 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -547,4 +547,3 @@ int dma_direct_set_offset(struct device *dev, phys_addr_t cpu_start,
dev->dma_range_map = map;
return 0;
}
-EXPORT_SYMBOL_GPL(dma_direct_set_offset);
--
2.28.0
Hi Christoph, Chen-Yu, Hans,
On Fri, Nov 06, 2020 at 05:07:37PM +0100, Christoph Hellwig wrote:
> Thanks,
>
> this looks good to me:
>
> Reviewed-by: Christoph Hellwig <[email protected]>
>
> Can you include this patch at the end of your series to that it gets
> picked up with the other patches?
I guess the easiest to avoid bisection issues would be to merge all this
through drm-misc, would that work for you?
Maxime
On Mon, Nov 09, 2020 at 10:43:03AM +0100, Maxime Ripard wrote:
> Hi Christoph, Chen-Yu, Hans,
>
> On Fri, Nov 06, 2020 at 05:07:37PM +0100, Christoph Hellwig wrote:
> > Thanks,
> >
> > this looks good to me:
> >
> > Reviewed-by: Christoph Hellwig <[email protected]>
> >
> > Can you include this patch at the end of your series to that it gets
> > picked up with the other patches?
>
> I guess the easiest to avoid bisection issues would be to merge all this
> through drm-misc, would that work for you?
Fine with me!
On 06/11/2020 16:14, Maxime Ripard wrote:
> Hi,
>
> Here's an attempt to removing the dma_direct_set_offset calls we have in
> numerous drivers and move all those quirks into a global notifier as suggested
> by Robin.
For patches 4-7:
Acked-by: Hans Verkuil <[email protected]>
It's fine by me if this series is merged via the drm subsystem.
Regards,
Hans
>
> Let me know what you think,
> Maxime
>
> Maxime Ripard (7):
> drm/sun4i: backend: Fix probe failure with multiple backends
> soc: sunxi: Deal with the MBUS DMA offsets in a central place
> drm/sun4i: backend: Remove the MBUS quirks
> media: sun4i: Remove the MBUS quirks
> media: sun6i: Remove the MBUS quirks
> media: cedrus: Remove the MBUS quirks
> media: sun8i-di: Remove the call to of_dma_configure
>
> drivers/gpu/drm/sun4i/sun4i_backend.c | 13 --
> .../platform/sunxi/sun4i-csi/sun4i_csi.c | 27 ----
> .../platform/sunxi/sun6i-csi/sun6i_csi.c | 17 ---
> .../media/platform/sunxi/sun8i-di/sun8i-di.c | 4 -
> drivers/soc/sunxi/Kconfig | 8 ++
> drivers/soc/sunxi/Makefile | 1 +
> drivers/soc/sunxi/sunxi_mbus.c | 132 ++++++++++++++++++
> drivers/staging/media/sunxi/cedrus/cedrus.c | 1 -
> drivers/staging/media/sunxi/cedrus/cedrus.h | 3 -
> .../staging/media/sunxi/cedrus/cedrus_hw.c | 18 ---
> 10 files changed, 141 insertions(+), 83 deletions(-)
> create mode 100644 drivers/soc/sunxi/sunxi_mbus.c
>
On Mon, Nov 09, 2020 at 10:43:03AM +0100, Maxime Ripard wrote:
> Hi Christoph, Chen-Yu, Hans,
>
> On Fri, Nov 06, 2020 at 05:07:37PM +0100, Christoph Hellwig wrote:
> > Thanks,
> >
> > this looks good to me:
> >
> > Reviewed-by: Christoph Hellwig <[email protected]>
> >
> > Can you include this patch at the end of your series to that it gets
> > picked up with the other patches?
>
> I guess the easiest to avoid bisection issues would be to merge all this
> through drm-misc, would that work for you?
Is this going to get picked up in drm-misc? I don't see it in linux-next
so far.
Hi Christoph,
On Thu, Nov 19, 2020 at 08:59:59AM +0100, Christoph Hellwig wrote:
> On Mon, Nov 09, 2020 at 10:43:03AM +0100, Maxime Ripard wrote:
> > Hi Christoph, Chen-Yu, Hans,
> >
> > On Fri, Nov 06, 2020 at 05:07:37PM +0100, Christoph Hellwig wrote:
> > > Thanks,
> > >
> > > this looks good to me:
> > >
> > > Reviewed-by: Christoph Hellwig <[email protected]>
> > >
> > > Can you include this patch at the end of your series to that it gets
> > > picked up with the other patches?
> >
> > I guess the easiest to avoid bisection issues would be to merge all this
> > through drm-misc, would that work for you?
>
> Is this going to get picked up in drm-misc? I don't see it in linux-next
> so far.
After some discussion with Arnd and Daniel, this will go through
arm-soc, and I sent the PR here:
https://lore.kernel.org/linux-arm-kernel/[email protected]/
It hasn't been merged yet though
Maxime