Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1
On Thu, Jun 23, 2022 at 12:05 PM sascha hauer wrote: > Also consider SoCs in early upstreaming phases > when the device tree is merged with "dmas" or "hwlock" properties, > but the corresponding drivers are not yet upstreamed. It's not nice > to defer probing of all these devices for a long time. Actually this drives a truck through the entire approach in a way. It is perfectly legal to have a device tree with dmas specified but leave them unused in the operating system. DT just describes what hardware is there, it does not mandate that the OS implement drivers for all of it. This approach really needs that the resolution mechanism is aware of whether: 1. a driver exist for the resource at all so it will eventually resolve 2. if that driver is compiled in or module at all (IS_ENABLED()) 3. If the resource should be grabbed early or optionally later such as dmas for console UART Only then can the mechanism work in the generic case. Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 7/9] driver core: Set fw_devlink.strict=1 by default
On Wed, Jun 22, 2022 at 9:40 PM Saravana Kannan wrote: > Actually, why isn't earlyconsole being used? That doesn't get blocked > on anything and the main point of that is to have console working from > really early on. For Arm (arch/arm) there is a special low-level debug option call low-level debug, which you find in e.g: arch/arm/Kconfig.debug arch/arm/kernel/debug.S This debug facility can print to the UART fifo before even MMU is up, pretty much from the first instruction the kernel executes. The versatility of LL-debug means that developers do not use earlyconsole much on Arm. I don't know about arm64 though. Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 7/9] driver core: Set fw_devlink.strict=1 by default
On Wed, Jun 22, 2022 at 9:48 AM Sascha Hauer wrote: > This patch has the effect that console UART devices which have "dmas" > properties specified in the device tree get deferred for 10 to 20 > seconds. This happens on i.MX and likely on other SoCs as well. On i.MX > the dma channel is only requested at UART startup time and not at probe > time. dma is not used for the console. Nevertheless with this driver probe > defers until the dma engine driver is available. > > It shouldn't go in as-is. This affects all machines with the PL011 UART and DMAs specified as well. It would be best if the console subsystem could be treated special and not require DMA devlink to be satisfied before probing. It seems devlink is not quite aware of the concept of resources that are necessary to probe vs resources that are nice to have and might be added after probe. We need a strong devlink for the first category and maybe a weak devlink for the latter category. I don't know if this is a generic hardware property for all operating systems so it could be a DT property such as dma-weak-dependency? Or maybe compromize and add a linux,dma-weak-dependency; property? Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: fully convert arm to use dma-direct
On Mon, May 9, 2022 at 5:44 PM Russell King (Oracle) wrote: > Assabet is what needs testing for that, or one of the SA1110 machines. > I'm away from home on my boat (and have been for the last two and a bit > weeks) so can't test. Sorry. Hm I actually have an Assabet, but I never even powered it up. I'm on parental leave for another week but after that I could actually try to get that machine up, but it'd be a bit late for this merge window indeed. BR Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: fully convert arm to use dma-direct
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote: > arm is the last platform not using the dma-direct code for directly > mapped DMA. With the dmaboune removal from Arnd we can easily switch > arm to always use dma-direct now (it already does for LPAE configs > and nommu). I'd love to merge this series through the dma-mapping tree > as it gives us the opportunity for additional core dma-mapping > improvements. (...) > b/arch/arm/mach-footbridge/Kconfig |1 > b/arch/arm/mach-footbridge/common.c | 19 > b/arch/arm/mach-footbridge/include/mach/dma-direct.h |8 > b/arch/arm/mach-footbridge/include/mach/memory.h |4 I think Marc Z has a Netwinder that he can test this on. Marc? I have one too, just not much in my office because of parental leave. Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 11/13 v2] ARM: ixp4xx: Drop custom DMA coherency and bouncing
The new PCI driver does not need any of this stuff, so just
drop it.
Cc: iommu@lists.linux-foundation.org
Reviewed-by: Christoph Hellwig
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Pick up Christoph's Reviewed-by and add proper CC for iommu
- Resending with the rest
---
arch/arm/Kconfig | 5 ---
arch/arm/mach-ixp4xx/common.c | 57 ---
kernel/dma/mapping.c | 2 --
3 files changed, 64 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3a95203236d2..ec0dbaf73a81 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -217,9 +217,6 @@ config ARCH_MAY_HAVE_PC_FDC
config ARCH_SUPPORTS_UPROBES
def_bool y
-config ARCH_HAS_DMA_SET_COHERENT_MASK
- bool
-
config GENERIC_ISA_DMA
bool
@@ -381,10 +378,8 @@ config ARCH_IOP32X
config ARCH_IXP4XX
bool "IXP4xx-based"
depends on MMU
- select ARCH_HAS_DMA_SET_COHERENT_MASK
select ARCH_SUPPORTS_BIG_ENDIAN
select CPU_XSCALE
- select DMABOUNCE if PCI
select GENERIC_IRQ_MULTI_HANDLER
select GPIO_IXP4XX
select GPIOLIB
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 4e51514ace6d..310e1602fbfc 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -30,7 +30,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -330,59 +329,3 @@ void ixp4xx_restart(enum reboot_mode mode, const char *cmd)
*IXP4XX_OSWE = IXP4XX_WDT_RESET_ENABLE |
IXP4XX_WDT_COUNT_ENABLE;
}
}
-
-#ifdef CONFIG_PCI
-static int ixp4xx_needs_bounce(struct device *dev, dma_addr_t dma_addr, size_t
size)
-{
- return (dma_addr + size) > SZ_64M;
-}
-
-static int ixp4xx_platform_notify_remove(struct device *dev)
-{
- if (dev_is_pci(dev))
- dmabounce_unregister_dev(dev);
-
- return 0;
-}
-#endif
-
-/*
- * Setup DMA mask to 64MB on PCI devices and 4 GB on all other things.
- */
-static int ixp4xx_platform_notify(struct device *dev)
-{
- dev->dma_mask = >coherent_dma_mask;
-
-#ifdef CONFIG_PCI
- if (dev_is_pci(dev)) {
- dev->coherent_dma_mask = DMA_BIT_MASK(28); /* 64 MB */
- dmabounce_register_dev(dev, 2048, 4096, ixp4xx_needs_bounce);
- return 0;
- }
-#endif
-
- dev->coherent_dma_mask = DMA_BIT_MASK(32);
- return 0;
-}
-
-int dma_set_coherent_mask(struct device *dev, u64 mask)
-{
- if (dev_is_pci(dev))
- mask &= DMA_BIT_MASK(28); /* 64 MB */
-
- if ((mask & DMA_BIT_MASK(28)) == DMA_BIT_MASK(28)) {
- dev->coherent_dma_mask = mask;
- return 0;
- }
-
- return -EIO;/* device wanted sub-64MB mask */
-}
-EXPORT_SYMBOL(dma_set_coherent_mask);
-
-void __init ixp4xx_init_early(void)
-{
- platform_notify = ixp4xx_platform_notify;
-#ifdef CONFIG_PCI
- platform_notify_remove = ixp4xx_platform_notify_remove;
-#endif
-}
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 9478eccd1c8e..559461a826ba 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -745,7 +745,6 @@ int dma_set_mask(struct device *dev, u64 mask)
}
EXPORT_SYMBOL(dma_set_mask);
-#ifndef CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK
int dma_set_coherent_mask(struct device *dev, u64 mask)
{
/*
@@ -761,7 +760,6 @@ int dma_set_coherent_mask(struct device *dev, u64 mask)
return 0;
}
EXPORT_SYMBOL(dma_set_coherent_mask);
-#endif
size_t dma_max_mapping_size(struct device *dev)
{
--
2.34.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft dependencies on DMA_CMA
On Fri, Apr 9, 2021 at 1:20 PM David Hildenbrand wrote: > Random drivers should not override a user configuration of core knobs > (e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA, > which depends on CMA, if possible; however, these drivers also have to > tolerate if DMA_CMA is not available/functioning, for example, if no CMA > area for DMA_CMA use has been setup via "cma=X". In the worst case, the > driver cannot do it's job properly in some configurations. Looks good to me. At least a lot better than what we have. Reviewed-by: Linus Walleij > Let's see if this approach is better for soft dependencies (and if we > actually have some hard dependencies in there). This is the follow-up > of > https://lkml.kernel.org/r/20210408092011.52763-1-da...@redhat.com > https://lkml.kernel.org/r/20210408100523.63356-1-da...@redhat.com You can just add these to the commit message with Link: when applying so people can easily find the discussion from the commit. > I was wondering if it would make sense in some drivers to warn if either > CONFIG_DMA_CMA is not available or if DRM_CMA has not been configured > properly - just to give people a heads up that something might more likely > go wrong; that would, however, be future work. I think the frameworks (DRM_*_CMA_HELPER) should pr_info something about it so the individual drivers don't have to sanity check their entire world. Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples
On Tue, Feb 2, 2021 at 9:55 PM Rob Herring wrote: > Running 'dt-validate -m' will flag any compatible strings missing a schema. > Fix all the errors found in DT binding examples. Most of these are just > typos. > > Cc: Stephen Boyd > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Linus Walleij > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Daniel Palmer > Cc: Bartosz Golaszewski > Cc: Avi Fishman > Cc: Tomer Maimon > Cc: Tali Perry > Cc: Joerg Roedel > Cc: Will Deacon > Cc: Andrew Jeffery > Cc: Joel Stanley > Cc: Wim Van Sebroeck > Cc: Guenter Roeck > Cc: Yoshihiro Shimoda > Cc: Vincent Cheng > Cc: linux-...@vger.kernel.org > Cc: linux-cry...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-watch...@vger.kernel.org > Signed-off-by: Rob Herring Ooops. Reviewed-by: Linus Walleij Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 3/3] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
On Mon, Nov 16, 2020 at 5:36 PM Will Deacon wrote: > Linus -- please can you drop this one (patch 3/3) for now, given that it's > causing problems? Reverted now, sorry for missing to do this earlier. Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 3/3] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
On Fri, Nov 6, 2020 at 5:27 AM John Stultz wrote: > Allow the qcom_scm driver to be loadable as a permenent module. > > This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to > ensure that drivers that call into the qcom_scm driver are > also built as modules. While not ideal in some cases its the > only safe way I can find to avoid build errors without having > those drivers select QCOM_SCM and have to force it on (as > QCOM_SCM=n can be valid for those drivers). > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Joerg Roedel > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > Cc: Linus Walleij > Cc: Vinod Koul > Cc: Kalle Valo > Cc: Maulik Shah > Cc: Lina Iyer > Cc: Saravana Kannan > Cc: Todd Kjos > Cc: Greg Kroah-Hartman > Cc: linux-arm-...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-g...@vger.kernel.org > Acked-by: Kalle Valo > Acked-by: Greg Kroah-Hartman > Reviewed-by: Bjorn Andersson > Signed-off-by: John Stultz I applied this patch to the pinctrl tree as well, I suppose that was the intention. If someone gets upset I can always pull it out. Thanks for your perseverance in driving this John. Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 2/3] pinctrl: qcom: Allow pinctrl-msm code to be loadable as a module
On Fri, Nov 6, 2020 at 5:27 AM John Stultz wrote: > Tweaks to allow pinctrl-msm code to be loadable as a module. > > This is needed in order to support having the qcom-scm driver, > which pinctrl-msm calls into, configured as a module. > > This requires that we tweak Kconfigs selecting PINCTRL_MSM to > also depend on QCOM_SCM || QCOM_SCM=n so that we match the > module setting of QCOM_SCM. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Joerg Roedel > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > Cc: Linus Walleij > Cc: Vinod Koul > Cc: Kalle Valo > Cc: Maulik Shah > Cc: Lina Iyer > Cc: Saravana Kannan > Cc: Todd Kjos > Cc: Greg Kroah-Hartman > Cc: linux-arm-...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-g...@vger.kernel.org > Reviewed-by: Bjorn Andersson > Signed-off-by: John Stultz Patch applied! Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 1/3] pinctrl: qcom: Kconfig: Rework PINCTRL_MSM to be a depenency rather then a selected config
On Fri, Nov 6, 2020 at 5:27 AM John Stultz wrote: > This patch reworks PINCTRL_MSM to be a visible option, and > instead of having the various SoC specific drivers select > PINCTRL_MSM, this switches those configs to depend on > PINCTRL_MSM. > > This is useful, as it will be needed in order to cleanly support > having the qcom-scm driver, which pinctrl-msm calls into, > configured as a module. Without this change, we would eventually > have to add dependency lines to every config that selects > PINCTRL_MSM, and that would becomes a maintenance headache. > > We also add PINCTRL_MSM to the arm64 defconfig to avoid > surprises as otherwise PINCTRL_MSM/IPQ* options previously > enabled, will be off. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Joerg Roedel > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > Cc: Linus Walleij > Cc: Vinod Koul > Cc: Kalle Valo > Cc: Maulik Shah > Cc: Lina Iyer > Cc: Saravana Kannan > Cc: Todd Kjos > Cc: Greg Kroah-Hartman > Cc: linux-arm-...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-g...@vger.kernel.org > Reviewed-by: Bjorn Andersson > Signed-off-by: John Stultz Patch applied! Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 1/2] pinctrl: qcom: Allow pinctrl-msm code to be loadable as a module
On Sat, Oct 31, 2020 at 1:38 AM John Stultz wrote: > Tweaks to allow pinctrl-msm code to be loadable as a module. > > This is needed in order to support having the qcom-scm driver, > which pinctrl-msm calls into, configured as a module. > > This requires that we tweak Kconfigs selecting PINCTRL_MSM to > also depend on QCOM_SCM || QCOM_SCM=n so that we match the > module setting of QCOM_SCM. > > Unlike the previous revision of this patch: > https://lore.kernel.org/lkml/20200625001039.56174-5-john.stu...@linaro.org/ > this version reworks PINCTRL_MSM to be a visible option and > instead of having the various SoC specific drivers select > PINCTRL_MSM, this switches those configs to depend on > PINCTRL_MSM. This avoids adding the oddish looking: > "depend on QCOM_SCM || QCOM_SCM=n" > to every SoC specific driver, as that becomes a maintenance > headache. > > We also add PINCTRL_MSM to the arm64 defconfig to avoid > surprises as otherwise PINCTRL_MSM/IPQ* options previously > enabled, will be off. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Joerg Roedel > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > Cc: Linus Walleij > Cc: Vinod Koul > Cc: Kalle Valo > Cc: Maulik Shah > Cc: Lina Iyer > Cc: Saravana Kannan > Cc: Todd Kjos > Cc: Greg Kroah-Hartman > Cc: linux-arm-...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-g...@vger.kernel.org > Signed-off-by: John Stultz > --- > v2: > * Module description and whitespace fixes suggested by Bjorn > * Added QCOM_SCM || QCOM_SCM=n bits on Kconfigs selecting > PINCTRL_MSM. Reported by both Todd and Bjorn. > v3: > * Make sure the QCOM_SCM || QCOM_SCM=n trick is commented > v4: > * Rework "select PINCTRL_MSM" to "depends on PINCTRL_MSM" > to consolidate the QCOM_SCM dependency. > v5: > * Add PINCTRL_MSM to arm64 defconfig Bjorn can you have a look at this series? BTW John I'm afraid I just merged a new QCOM subdriver so we might need to respin this to cover all. It's an important patch so I'll help out in rebasing it if the only problem is that my tree is moving under your feet. Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/3] Allow for qcom-pdc to be loadable as a module
On Sat, Jul 11, 2020 at 1:18 AM John Stultz wrote: > This patch series provides exports and config tweaks to allow > the qcom-pdc driver to be able to be configured as a permement > modules (particularlly useful for the Android Generic Kernel > Image efforts). > > This was part of a larger patch series, to enable qcom_scm > driver to be a module as well, but I've split it out as there > are some outstanding objections I still need to address with > the follow-on patches, and wanted to see if progress could be > made on this subset of the series in the meantime. > > New in v3: > * Drop conditional usage of IRQCHIP_DECLARE as suggested by >Stephen Boyd and Marc Zyngier This patch set looks entirely reasonable to me. Reviewed-by: Linus Walleij Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC][PATCH 4/5] pinctrl: qcom: Allow pinctrl-msm code to be loadable as a module
On Tue, Jun 16, 2020 at 8:13 AM John Stultz wrote: > Tweaks to allow pinctrl-msm code to be loadable as a module. > This is needed in order to support having the qcom-scm driver, > which pinctrl-msm calls into, configured as a module. > > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Joerg Roedel > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > Cc: Linus Walleij > Cc: Lina Iyer > Cc: Saravana Kannan > Cc: Todd Kjos > Cc: Greg Kroah-Hartman > Cc: linux-arm-...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-g...@vger.kernel.org > Signed-off-by: John Stultz Unless there are dependencies on the irqchip patches I can apply this if Bjorn is OK with it. Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: remove block layer bounce buffering for MMC
On Wed, Jan 16, 2019 at 11:25 AM Arnd Bergmann wrote: > On Mon, Jan 14, 2019 at 11:27 AM Ulf Hansson wrote: > > > > +Linus Walleij (recently made a cleanup of the mmc bounce buffering code). Nah it's not THAT bounce buffer. > Linus probably knows more here, but I have a vague recollection of > the MMC bounce buffer code being needed mostly for performance > reasons: when the scatterlist is discontiguous, that can result in > a request being split up into separate MMC commands, which due > to the lack of queued commands combined with the need for > garbage collection on sub-page writes results in a huge slowdown > compared to having larger bounce buffers all the time. > > We had discussed finding a different way to do this (separate > from the bounce buffering), but I don't know if that ever happened, > or if this is even the code that you are changing here. Nope not the same code. The term "bounce buffer" is sadly used as ambigously as __underscores in front of function names. That other "bounce buffer" was first deleted and then reimplemented as a local hack in the SDHCI driver core after it caused performance regressions on the i.MX and some laptops, see commit: commit bd9b902798ab14d19ca116b10bde581ddff8f905 mmc: sdhci: Implement an SDHCI-specific bounce buffer That should be orthogonal to Christoph's changes in this patch series. Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3] of/platform: initialise AMBA default DMA masks
This addresses a v4.19-rc1 regression in the PL111 DRM driver
in drivers/gpu/pl111/*
The driver uses the CMA KMS helpers and will thus at some
point call down to dma_alloc_attrs() to allocate a chunk
of contigous DMA memory for the framebuffer.
It appears that in v4.18, it was OK that this (and other
DMA mastering AMBA devices) left dev->coherent_dma_mask
blank (zero).
In v4.19-rc1 the WARN_ON_ONCE(dev && !dev->coherent_dma_mask)
in dma_alloc_attrs() in include/linux/dma-mapping.h is
triggered. The allocation later fails when get_coherent_dma_mask()
is called from __dma_alloc() and __dma_alloc() returns
NULL:
drm-clcd-pl111 dev:20: coherent DMA mask is unset
drm-clcd-pl111 dev:20: [drm:drm_fb_helper_fbdev_setup] *ERROR*
Failed to set fbdev configuration
It turns out that in commit 4d8bde883bfb
("OF: Don't set default coherent DMA mask")
the OF core stops setting the default DMA mask on new devices,
especially those lines of the patch:
- if (!dev->coherent_dma_mask)
- dev->coherent_dma_mask = DMA_BIT_MASK(32);
Robin Murphy solved a similar problem in
a5516219b102 ("of/platform: Initialise default DMA masks")
by simply assigning dev.coherent_dma_mask and the
dev.dma_mask to point to the same when creating devices
from the device tree, and introducing the same code into
the code path creating AMBA/PrimeCell devices solved my
problem, graphics now come up.
The code simply assumes that the device can access all
of the system memory by setting the coherent DMA mask
to 0x when creating a device from the device
tree, which is crude, but seems to be what kernel v4.18
assumed.
The AMBA PrimeCells do not differ between coherent and
streaming DMA so we can just assign the same to any
DMA mask.
Possibly drivers should augment their coherent DMA mask
in accordance with "dma-ranges" from the device tree
if more finegranular masking is needed.
Reported-by: Russell King
Fixes: 4d8bde883bfb ("OF: Don't set default coherent DMA mask")
Cc: Russell King
Cc: Christoph Hellwig
Cc: Robin Murphy
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Provide proper root cause analysis, point to the right
offending commit with Fixes:
- Make even more elaborate description of what is causing
this.
ChangeLog v1->v2:
- Provide a better description for the change.
---
drivers/of/platform.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7ba90c290a42..6c59673933e9 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -241,6 +241,10 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
if (!dev)
goto err_clear_flag;
+ /* AMBA devices only support a single DMA mask */
+ dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ dev->dev.dma_mask = >dev.coherent_dma_mask;
+
/* setup generic device info */
dev->dev.of_node = of_node_get(node);
dev->dev.fwnode = >fwnode;
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2] of/platform: initialise AMBA default DMA masks
This addresses a v4.19-rc1 regression in the PL111 DRM driver
in drivers/gpu/pl111/*
The driver uses the CMA KMS helpers and will thus at some
point call down to dma_alloc_attrs() to allocate a chunk
of contigous DMA memory for the framebuffer.
It appears that in v4.18, it was OK that this (and other
DMA mastering AMBA devices) left dev->coherent_dma_mask
blank (zero).
In v4.19-rc1 the WARN_ON_ONCE(dev && !dev->coherent_dma_mask)
in dma_alloc_attrs() in include/linux/dma-mapping.h is
triggered. The allocation later fails when get_coherent_dma_mask()
is called from __dma_alloc() and __dma_alloc() returns
NULL:
drm-clcd-pl111 dev:20: coherent DMA mask is unset
drm-clcd-pl111 dev:20: [drm:drm_fb_helper_fbdev_setup] *ERROR*
Failed to set fbdev configuration
I have not been able to properly bisect down to the actual
committ causing it beacuse the kernel simply fails to build
at to many bisection points, pushing the bisect back to places
like the merge of entire subsystem trees, where things have
likely been resolved while merging them.
I found that Robin Murphy solved a similar problem in
a5516219b102 ("of/platform: Initialise default DMA masks")
by simply assigning dev.coherent_dma_mask and the
dev.dma_mask to point to the same when creating devices
from the device tree, and introducing the same code into
the code path creating AMBA/PrimeCell devices solved my
problem, graphics now come up.
The code simply assumes that the device can access all
of the system memory by setting the coherent DMA mask
to 0x when creating a device from the device
tree, which is crude, but seems to be what kernel v4.18
assumed.
Cc: Russell King
Cc: Christoph Hellwig
Cc: Robin Murphy
Signed-off-by: Linus Walleij
---
Russell, Christoph: this is probably not the last patch.
But it has a more accurate description of the problem.
I still do not know what change to the kernel made
it start triggering this, whether in the DMA API or
in DRM :(
I am looking into Russell's suggestion to use the DMA
ranges, and thusly patch all device trees with DMA
mastering devices adding DMA ranges to them and parsing
that in the device tree AMBA/PrimeCell population code.
Possibly that is the right path forward.
---
drivers/of/platform.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7ba90c290a42..6c59673933e9 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -241,6 +241,10 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
if (!dev)
goto err_clear_flag;
+ /* AMBA devices only support a single DMA mask */
+ dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ dev->dev.dma_mask = >dev.coherent_dma_mask;
+
/* setup generic device info */
dev->dev.of_node = of_node_get(node);
dev->dev.fwnode = >fwnode;
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] of/platform: Initialise AMBA default DMA masks
On Thu, Aug 30, 2018 at 10:40 AM Russell King - ARM Linux wrote: > Well, as I've no idea what the issue is here, I can't do anything or > make any suggestions. I wasn't copied on the initial part of the > thread. Sorry about that, it was because the original patch only hit in drivers/of/*. I will send you a copy of the thread. Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: various dma_mask fixups
On Wed, Aug 29, 2018 at 8:24 AM Christoph Hellwig wrote: > Fix warnings and regressions from requiring a dma mask. Applied all three patches and took a few ARM systems for a test ride: Tested-by: Linus Walleij Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] of/platform: Initialise AMBA default DMA masks
On Tue, Aug 28, 2018 at 11:21 AM Christoph Hellwig wrote: > > + dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > > + if (!dev->dev.dma_mask) > > + dev->dev.dma_mask = >dev.coherent_dma_mask; > > We should never set dma_mask to point to the coherent_dma_mask, > as that will cause problems with devices that have different > mask for the two. > > How about something like this? (...) > + u64 dma_mask; We did that before, so this becomes effectively a revert of: commit 446b2a9380b64b9d7410d86ee8226031e03645cf DMA-API: amba: get rid of separate dma_mask AMBA Primecell devices always treat streaming and coherent DMA exactly the same, so there's no point in having the masks separated. So there is some history around this. There is also some code in drivers/amba/bus.c affected by that and I need to look over all static amba device allocations if we reintroduce this. That said, the remaining static allocations (a.k.a. boardfiles) appear to be very few and very limited, almost all systems use device tree or ACPI or iterative dynamic allocation (from amba/bus.c functions) of the amba devices now. Do you think we can proceed with this patch or do you want me to revert the split back? FWIW the platform devices have the same problem, but I know I know, two wrongs does not make one right :/ Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] of/platform: Initialise AMBA default DMA masks
commit a5516219b102 ("of/platform: Initialise default DMA masks")
sets up the coherent_dma_mask of platform devices created
from the device tree, but fails to do the same for AMBA
(PrimeCell) devices.
This leads to a regression in kernel v4.19-rc1 triggering the
WARN_ONCE() in kernel/dma/coherent.c, dma_alloc_attrs()
WARN_ON_ONCE(dev && !dev->coherent_dma_mask):
[ cut here ]
WARNING: CPU: 0 PID: 1 at ../include/linux/dma-mapping.h:522
drm_gem_cma_create+0x1dc/0x21c
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc1+ #15
Hardware name: ARM-Versatile (Device Tree Support)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (__warn+0xcc/0xf4)
[] (__warn) from [] (warn_slowpath_null+0x3c/0x48)
[] (warn_slowpath_null) from []
(drm_gem_cma_create+0x1dc/0x21c)
[] (drm_gem_cma_create) from []
(drm_gem_cma_dumb_create+0x44/0x98)
[] (drm_gem_cma_dumb_create) from []
(drm_client_framebuffer_create+0x80/0x204)
[] (drm_client_framebuffer_create) from []
(drm_fb_helper_generic_probe+0x4c/0x200)
[] (drm_fb_helper_generic_probe) from []
(__drm_fb_helper_initial_config_and_unlock+0x1cc/0x454)
[] (__drm_fb_helper_initial_config_and_unlock) from []
(drm_fb_helper_fbdev_setup+0x104/0x218)
[] (drm_fb_helper_fbdev_setup) from []
(drm_fbdev_cma_init+0x7c/0xac)
[] (drm_fbdev_cma_init) from []
(drm_fb_cma_fbdev_init+0x8/0x14)
[] (drm_fb_cma_fbdev_init) from []
(pl111_amba_probe+0x3c8/0x4a4)
[] (pl111_amba_probe) from [] (amba_probe+0xd8/0x154)
[] (amba_probe) from [] (really_probe+0x200/0x2ac)
[] (really_probe) from [] (driver_probe_device+0x5c/0x168)
[] (driver_probe_device) from [] (__driver_attach+0xd0/0xd4)
[] (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4)
[] (bus_for_each_dev) from [] (bus_add_driver+0x170/0x204)
[] (bus_add_driver) from [] (driver_register+0x74/0x108)
[] (driver_register) from [] (do_one_initcall+0x48/0x1a0)
[] (do_one_initcall) from []
(kernel_init_freeable+0x104/0x1c4)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0)
[] (kernel_init) from [] (ret_from_fork+0x14/0x34)
Exception stack(0xc781ffb0 to 0xc781fff8)
ffa0:
ffc0:
ffe0: 0013
---[ end trace 2dc47eb796bde006 ]---
This regresses the PL111 DRM driver in drivers/gpu/drm/pl111
that uses the AMBA PrimeCell to instantiate the frame buffer
device, as it cannot allocate a chunk of coherent memory
anymore due to the missing mask.
Fixes: a5516219b102 ("of/platform: Initialise default DMA masks")
Cc: Robin Murphy
Cc: Rob Herring
Cc: Christoph Hellwig
Cc: Eric Anholt
Cc: Noralf Trønnes
Signed-off-by: Linus Walleij
---
I don't know which tree Robins patch came in from, but I assume
Christoph's, so can you carry this patch as well?
---
drivers/of/platform.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7ba90c290a42..7435c79ca56d 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -242,6 +242,9 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
goto err_clear_flag;
/* setup generic device info */
+ dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ if (!dev->dev.dma_mask)
+ dev->dev.dma_mask = >dev.coherent_dma_mask;
dev->dev.of_node = of_node_get(node);
dev->dev.fwnode = >fwnode;
dev->dev.parent = parent ? : _bus;
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
On Mon, Oct 28, 2013 at 4:46 PM, Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com wrote: If you believe the issue should be solved in a different way (for instance by removing the architecture dependency completely) please reply to the cover letter to let other maintainers chime in. I have no real opinions on whether this is a good itermediate step towards complete arch-independence or not, but I just noticed that you still have the mach/* hierarchy in mach-shmobile/include/mach/*, and grep:ing around this seems totally unnecessary, I think it would be easy to produce a patch set eliminating mach/* from shmobile. (Usually we will just move all the headers down into the mach-shmobile folder.) Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
