* Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates [not found] ` <20191015131750.GV25745@shell.armlinux.org.uk> @ 2019-10-23 5:42 ` Michael Ellerman 2019-10-23 6:41 ` Benjamin Herrenschmidt 2019-10-23 14:20 ` Christian Zigotzky 0 siblings, 2 replies; 21+ messages in thread From: Michael Ellerman @ 2019-10-23 5:42 UTC (permalink / raw) To: Russell King - ARM Linux admin, Christian Zigotzky, Benjamin Herrenschmidt, Paul Mackerras Cc: ulf.hansson, R.T.Dickinson, linux-mmc, Rob Herring, contact, mad skateman, linuxppc-dev, Christian Zigotzky Russell King - ARM Linux admin <linux@armlinux.org.uk> writes: > On Tue, Oct 15, 2019 at 03:12:49PM +0200, Christian Zigotzky wrote: >> Hello Russell, >> >> You asked me about "dma-coherent" in the Cyrus device tree. Unfortunately I >> don't find the property "dma-coherent" in the dtb source files. >> >> Output of "fdtdump cyrus_p5020_eth_poweroff.dtb | grep dma": >> >> dma0 = "/soc@ffe000000/dma@100300"; >> dma1 = "/soc@ffe000000/dma@101300"; >> dma@100300 { >> compatible = "fsl,eloplus-dma"; >> dma-channel@0 { >> compatible = "fsl,eloplus-dma-channel"; >> dma-channel@80 { >> compatible = "fsl,eloplus-dma-channel"; >> dma-channel@100 { >> compatible = "fsl,eloplus-dma-channel"; >> dma-channel@180 { >> compatible = "fsl,eloplus-dma-channel"; >> dma@101300 { >> compatible = "fsl,eloplus-dma"; >> dma-channel@0 { >> compatible = "fsl,eloplus-dma-channel"; >> dma-channel@80 { >> compatible = "fsl,eloplus-dma-channel"; >> dma-channel@100 { >> compatible = "fsl,eloplus-dma-channel"; >> dma-channel@180 { >> compatible = "fsl,eloplus-dma-channel"; > > Hmm, so it looks like PowerPC doesn't mark devices that are dma > coherent with a property that describes them as such. > > I think this opens a wider question - what should of_dma_is_coherent() > return for PowerPC? It seems right now that it returns false for > devices that are DMA coherent, which seems to me to be a recipe for > future mistakes. Right, it seems of_dma_is_coherent() has baked in the assumption that devices are non-coherent unless explicitly marked as coherent. Which is wrong on all or at least most existing powerpc systems according to Ben. > Any ideas from the PPC maintainers? Fixing it at the source seems like the best option to prevent future breakage. So I guess that would mean making of_dma_is_coherent() return true/false based on CONFIG_NOT_COHERENT_CACHE on powerpc. We could do it like below, which would still allow the dma-coherent property to work if it ever makes sense on a future powerpc platform. I don't really know any of this embedded stuff well, so happy to take other suggestions on how to handle this mess. cheers diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c index 25aaa3903000..b96c9010acb6 100644 --- a/arch/powerpc/kernel/setup-common.c +++ b/arch/powerpc/kernel/setup-common.c @@ -760,6 +760,22 @@ static int __init check_cache_coherency(void) late_initcall(check_cache_coherency); #endif /* CONFIG_CHECK_CACHE_COHERENCY */ +#ifndef CONFIG_NOT_COHERENT_CACHE +/* + * For historical reasons powerpc kernels are built with hard wired knowledge of + * whether or not DMA accesses are cache coherent. Additionally device trees on + * powerpc do not typically support the dma-coherent property. + * + * So when we know that DMA is coherent, override arch_of_dma_is_coherent() to + * tell the drivers/of code that all devices are coherent regardless of whether + * they have a dma-coherent property. + */ +bool arch_of_dma_is_coherent(struct device_node *np) +{ + return true; +} +#endif + #ifdef CONFIG_DEBUG_FS struct dentry *powerpc_debugfs_root; EXPORT_SYMBOL(powerpc_debugfs_root); diff --git a/drivers/of/address.c b/drivers/of/address.c index 978427a9d5e6..3a4b2949a322 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -993,6 +993,14 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz } EXPORT_SYMBOL_GPL(of_dma_get_range); +/* + * arch_of_dma_is_coherent - Arch hook to determine if device is coherent for DMA + */ +bool __weak arch_of_dma_is_coherent(struct device_node *np) +{ + return false; +} + /** * of_dma_is_coherent - Check if device is coherent * @np: device node @@ -1002,8 +1010,12 @@ EXPORT_SYMBOL_GPL(of_dma_get_range); */ bool of_dma_is_coherent(struct device_node *np) { - struct device_node *node = of_node_get(np); + struct device_node *node; + + if (arch_of_dma_is_coherent(np)) + return true; + np = of_node_get(np); while (node) { if (of_property_read_bool(node, "dma-coherent")) { of_node_put(node); ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates 2019-10-23 5:42 ` Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates Michael Ellerman @ 2019-10-23 6:41 ` Benjamin Herrenschmidt 2019-10-23 13:52 ` Rob Herring 2019-10-23 14:20 ` Christian Zigotzky 1 sibling, 1 reply; 21+ messages in thread From: Benjamin Herrenschmidt @ 2019-10-23 6:41 UTC (permalink / raw) To: Michael Ellerman, Russell King - ARM Linux admin, Christian Zigotzky, Paul Mackerras Cc: ulf.hansson, R.T.Dickinson, linux-mmc, Rob Herring, contact, mad skateman, linuxppc-dev, Christian Zigotzky On Wed, 2019-10-23 at 16:42 +1100, Michael Ellerman wrote: > > Right, it seems of_dma_is_coherent() has baked in the assumption that > devices are non-coherent unless explicitly marked as coherent. > > Which is wrong on all or at least most existing powerpc systems > according to Ben. This is probably broken on sparc(64) as well and whatever else uses DT and is an intrinsicly coherent architecture (did we ever have DT enabled x86s ? Wasn't OLPC such a beast ?). I think this should have been done the other way around and default to coherent since most traditional OF platforms are coherent, and you can't just require those DTs to change. > > Any ideas from the PPC maintainers? > > Fixing it at the source seems like the best option to prevent future > breakage. > > So I guess that would mean making of_dma_is_coherent() return true/false > based on CONFIG_NOT_COHERENT_CACHE on powerpc. > > We could do it like below, which would still allow the dma-coherent > property to work if it ever makes sense on a future powerpc platform. > > I don't really know any of this embedded stuff well, so happy to take > other suggestions on how to handle this mess. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates 2019-10-23 6:41 ` Benjamin Herrenschmidt @ 2019-10-23 13:52 ` Rob Herring 2019-10-23 14:12 ` Russell King - ARM Linux admin 2019-10-23 14:31 ` Russell King - ARM Linux admin 0 siblings, 2 replies; 21+ messages in thread From: Rob Herring @ 2019-10-23 13:52 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Ulf Hansson, mad skateman, linux-mmc, Russell King - ARM Linux admin, Paul Mackerras, R.T.Dickinson, Christian Zigotzky, contact, linuxppc-dev, Christian Zigotzky On Wed, Oct 23, 2019 at 1:41 AM Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > > On Wed, 2019-10-23 at 16:42 +1100, Michael Ellerman wrote: > > > > Right, it seems of_dma_is_coherent() has baked in the assumption that > > devices are non-coherent unless explicitly marked as coherent. > > > > Which is wrong on all or at least most existing powerpc systems > > according to Ben. > > This is probably broken on sparc(64) as well and whatever else uses > DT and is an intrinsicly coherent architecture (did we ever have > DT enabled x86s ? Wasn't OLPC such a beast ?). Only if those platforms use one of the 5 drivers that call this function: drivers/ata/ahci_qoriq.c: qoriq_priv->is_dmacoherent = of_dma_is_coherent(np); drivers/crypto/ccree/cc_driver.c: new_drvdata->coherent = of_dma_is_coherent(np); drivers/iommu/arm-smmu-v3.c: if (of_dma_is_coherent(dev->of_node)) drivers/iommu/arm-smmu.c: if (of_dma_is_coherent(dev->of_node)) drivers/mmc/host/sdhci-of-esdhc.c: if (of_dma_is_coherent(dev->of_node)) Curious that a PPC specific driver (ahci_qoriq) calls it... Note that the value is also passed to arch_setup_dma_ops(), but only arc, arm, arm64, and mips implement arch_setup_dma_ops. > I think this should have been done the other way around and default to > coherent since most traditional OF platforms are coherent, and you > can't just require those DTs to change. You can blame me. This was really only intended for cases where coherency is configurable on a per peripheral basis and can't be determined in other ways. The simple solution here is simply to use the compatible string for the device to determine coherent or not. Rob ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates 2019-10-23 13:52 ` Rob Herring @ 2019-10-23 14:12 ` Russell King - ARM Linux admin 2019-10-23 14:31 ` Russell King - ARM Linux admin 1 sibling, 0 replies; 21+ messages in thread From: Russell King - ARM Linux admin @ 2019-10-23 14:12 UTC (permalink / raw) To: Rob Herring Cc: Ulf Hansson, mad skateman, linux-mmc, Paul Mackerras, R.T.Dickinson, Christian Zigotzky, contact, linuxppc-dev, Christian Zigotzky On Wed, Oct 23, 2019 at 08:52:33AM -0500, Rob Herring wrote: > On Wed, Oct 23, 2019 at 1:41 AM Benjamin Herrenschmidt > <benh@kernel.crashing.org> wrote: > > > > On Wed, 2019-10-23 at 16:42 +1100, Michael Ellerman wrote: > > > > > > Right, it seems of_dma_is_coherent() has baked in the assumption that > > > devices are non-coherent unless explicitly marked as coherent. > > > > > > Which is wrong on all or at least most existing powerpc systems > > > according to Ben. > > > > This is probably broken on sparc(64) as well and whatever else uses > > DT and is an intrinsicly coherent architecture (did we ever have > > DT enabled x86s ? Wasn't OLPC such a beast ?). > > Only if those platforms use one of the 5 drivers that call this function: > > drivers/ata/ahci_qoriq.c: qoriq_priv->is_dmacoherent = > of_dma_is_coherent(np); > drivers/crypto/ccree/cc_driver.c: new_drvdata->coherent = > of_dma_is_coherent(np); > drivers/iommu/arm-smmu-v3.c: if (of_dma_is_coherent(dev->of_node)) > drivers/iommu/arm-smmu.c: if (of_dma_is_coherent(dev->of_node)) > drivers/mmc/host/sdhci-of-esdhc.c: if (of_dma_is_coherent(dev->of_node)) > > Curious that a PPC specific driver (ahci_qoriq) calls it... Maybe because it is not PPC specific: arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi: compatible = "fsl,lx2160a-ahci"; arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi: compatible = "fsl,lx2160a-ahci"; arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi: compatible = "fsl,lx2160a-ahci"; arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi: compatible = "fsl,lx2160a-ahci"; drivers/ata/ahci_qoriq.c: { .compatible = "fsl,lx2160a-ahci", .data = (void *)AHCI_LX2160A}, -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates 2019-10-23 13:52 ` Rob Herring 2019-10-23 14:12 ` Russell King - ARM Linux admin @ 2019-10-23 14:31 ` Russell King - ARM Linux admin 2019-10-25 22:28 ` Rob Herring 1 sibling, 1 reply; 21+ messages in thread From: Russell King - ARM Linux admin @ 2019-10-23 14:31 UTC (permalink / raw) To: Rob Herring Cc: Ulf Hansson, mad skateman, linux-mmc, Paul Mackerras, R.T.Dickinson, Christian Zigotzky, contact, linuxppc-dev, Christian Zigotzky On Wed, Oct 23, 2019 at 08:52:33AM -0500, Rob Herring wrote: > > I think this should have been done the other way around and default to > > coherent since most traditional OF platforms are coherent, and you > > can't just require those DTs to change. > > You can blame me. This was really only intended for cases where > coherency is configurable on a per peripheral basis and can't be > determined in other ways. > > The simple solution here is simply to use the compatible string for > the device to determine coherent or not. It really isn't that simple. There are two aspects to coherency, both of which must match: 1) The configuration of the device 2) The configuration of the kernel's DMA API (1) is controlled by the driver, which can make the decision any way it pleases. (2) on ARM64 is controlled depending on whether or not "dma-coherent" is specified in the device tree, since ARM64 can have a mixture of DMA coherent and non-coherent devices. A mismatch between (1) and (2) results in data corruption, potentially eating your filesystem. So, it's very important that the two match. These didn't match for the LX2160A, but, due to the way CMA was working, we sort of got away with it, but it was very dangerous as far as data safety went. Then, a change to CMA happened which moved where it was located, which caused a regression. Reverting the CMA changes didn't seem to be an option, so another solution had to be found. I started a discussion on how best to solve this: https://archive.armlinux.org.uk/lurker/thread/20190919.041320.1e53541f.en.html and the solution that the discussion came out with was the one that has been merged - which we now know caused a regression on PPC. Using compatible strings doesn't solve the issue: there is no way to tell the DMA API from the driver that the device is coherent. The only way to do that is via the "dma-coherent" property in DT on ARM64. To say that this is a mess is an under-statement, but we seem to have ended up here because of a series of piece-meal changes that don't seem to have been thought through enough. So, what's the right way to solve this, and ensure that the DMA API and device match as far as their coherency expectations go? Revert all the changes for sdhci-of-esdhc and CMA back to 5.0 or 5.1 state? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates 2019-10-23 14:31 ` Russell King - ARM Linux admin @ 2019-10-25 22:28 ` Rob Herring 2019-10-26 6:39 ` Christoph Hellwig 2019-10-28 8:45 ` Benjamin Herrenschmidt 0 siblings, 2 replies; 21+ messages in thread From: Rob Herring @ 2019-10-25 22:28 UTC (permalink / raw) To: Russell King - ARM Linux admin Cc: Ulf Hansson, mad skateman, linux-mmc, Paul Mackerras, R.T.Dickinson, Christian Zigotzky, contact, linuxppc-dev, Christian Zigotzky On Wed, Oct 23, 2019 at 9:32 AM Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > On Wed, Oct 23, 2019 at 08:52:33AM -0500, Rob Herring wrote: > > > I think this should have been done the other way around and default to > > > coherent since most traditional OF platforms are coherent, and you > > > can't just require those DTs to change. > > > > You can blame me. This was really only intended for cases where > > coherency is configurable on a per peripheral basis and can't be > > determined in other ways. > > > > The simple solution here is simply to use the compatible string for > > the device to determine coherent or not. > > It really isn't that simple. This doesn't work?: if (IS_ENABLED(CONFIG_PPC) || of_dma_is_coherent(dev->of_node)) value |= ESDHC_DMA_SNOOP; else value &= ~ESDHC_DMA_SNOOP; While I said use the compatibles, using the kconfig symbol is easier than sorting out which compatibles are PPC SoCs. Though if that's already done elsewhere in the driver, you could set a flag and use that here. I'd be surprised if this was the only difference between ARM and PPC SoCs for this block. > There are two aspects to coherency, both of which must match: > > 1) The configuration of the device > 2) The configuration of the kernel's DMA API > > (1) is controlled by the driver, which can make the decision any way > it pleases. > > (2) on ARM64 is controlled depending on whether or not "dma-coherent" > is specified in the device tree, since ARM64 can have a mixture of > DMA coherent and non-coherent devices. > > A mismatch between (1) and (2) results in data corruption, potentially > eating your filesystem. So, it's very important that the two match. > > These didn't match for the LX2160A, but, due to the way CMA was working, > we sort of got away with it, but it was very dangerous as far as data > safety went. > > Then, a change to CMA happened which moved where it was located, which > caused a regression. Reverting the CMA changes didn't seem to be an > option, so another solution had to be found. > > I started a discussion on how best to solve this: > > https://archive.armlinux.org.uk/lurker/thread/20190919.041320.1e53541f.en.html > > and the solution that the discussion came out with was the one that has > been merged - which we now know caused a regression on PPC. > > Using compatible strings doesn't solve the issue: there is no way to > tell the DMA API from the driver that the device is coherent. The > only way to do that is via the "dma-coherent" property in DT on ARM64. > > To say that this is a mess is an under-statement, but we seem to have > ended up here because of a series of piece-meal changes that don't seem > to have been thought through enough. > > So, what's the right way to solve this, and ensure that the DMA API and > device match as far as their coherency expectations go? Revert all the > changes for sdhci-of-esdhc and CMA back to 5.0 or 5.1 state? The other option is similar to earlier in the thread and just add to of_dma_is_coherent(): /* Powerpc is normally cache coherent DMA */ if (IS_ENABLED(CONFIG_PPC) && !IS_ENABLED(CONFIG_NOT_COHERENT_CACHE)) return true; We could do the all the weak arch hooks, but that seems like overkill to me at this point. Rob ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates 2019-10-25 22:28 ` Rob Herring @ 2019-10-26 6:39 ` Christoph Hellwig 2019-10-28 8:47 ` Benjamin Herrenschmidt 2019-10-28 8:45 ` Benjamin Herrenschmidt 1 sibling, 1 reply; 21+ messages in thread From: Christoph Hellwig @ 2019-10-26 6:39 UTC (permalink / raw) To: Rob Herring Cc: Ulf Hansson, mad skateman, linux-mmc, Russell King - ARM Linux admin, Paul Mackerras, R.T.Dickinson, Christian Zigotzky, contact, linuxppc-dev, Christian Zigotzky On Fri, Oct 25, 2019 at 05:28:45PM -0500, Rob Herring wrote: > This doesn't work?: > > if (IS_ENABLED(CONFIG_PPC) || of_dma_is_coherent(dev->of_node)) > value |= ESDHC_DMA_SNOOP; > else > value &= ~ESDHC_DMA_SNOOP; > > While I said use the compatibles, using the kconfig symbol is easier > than sorting out which compatibles are PPC SoCs. Though if that's > already done elsewhere in the driver, you could set a flag and use > that here. I'd be surprised if this was the only difference between > ARM and PPC SoCs for this block. I think the right thing is a Kconfig variable that the architectures selects which says if OF is by default coherent or incoherent, and then use that in of_dma_is_coherent. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates 2019-10-26 6:39 ` Christoph Hellwig @ 2019-10-28 8:47 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 21+ messages in thread From: Benjamin Herrenschmidt @ 2019-10-28 8:47 UTC (permalink / raw) To: Christoph Hellwig, Rob Herring Cc: Ulf Hansson, mad skateman, linux-mmc, Russell King - ARM Linux admin, Paul Mackerras, R.T.Dickinson, Christian Zigotzky, contact, linuxppc-dev, Christian Zigotzky On Fri, 2019-10-25 at 23:39 -0700, Christoph Hellwig wrote: > On Fri, Oct 25, 2019 at 05:28:45PM -0500, Rob Herring wrote: > > This doesn't work?: > > > > if (IS_ENABLED(CONFIG_PPC) || of_dma_is_coherent(dev- > > >of_node)) > > value |= ESDHC_DMA_SNOOP; > > else > > value &= ~ESDHC_DMA_SNOOP; > > > > While I said use the compatibles, using the kconfig symbol is > > easier > > than sorting out which compatibles are PPC SoCs. Though if that's > > already done elsewhere in the driver, you could set a flag and use > > that here. I'd be surprised if this was the only difference between > > ARM and PPC SoCs for this block. > > I think the right thing is a Kconfig variable that the architectures > selects which says if OF is by default coherent or incoherent, and > then use that in of_dma_is_coherent. That too. We could also define properties for both ways so we can override the default either way. Cheers, Ben. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates 2019-10-25 22:28 ` Rob Herring 2019-10-26 6:39 ` Christoph Hellwig @ 2019-10-28 8:45 ` Benjamin Herrenschmidt 1 sibling, 0 replies; 21+ messages in thread From: Benjamin Herrenschmidt @ 2019-10-28 8:45 UTC (permalink / raw) To: Rob Herring, Russell King - ARM Linux admin Cc: Ulf Hansson, mad skateman, linux-mmc, Paul Mackerras, R.T.Dickinson, Christian Zigotzky, contact, linuxppc-dev, Christian Zigotzky On Fri, 2019-10-25 at 17:28 -0500, Rob Herring wrote: > This doesn't work?: > > if (IS_ENABLED(CONFIG_PPC) || of_dma_is_coherent(dev- > >of_node)) > value |= ESDHC_DMA_SNOOP; > else > value &= ~ESDHC_DMA_SNOOP; CONFIG_PPC is restrictive. What about sparc64 ? There could be others .. .we can't suddenly requests people to add new properties for what was implied behaviours before hand, esp since it's not in the base 1275 spec, no ? I would suggest of_dma_is_coherent is *true* by default unless overriden to do something else. Cheers, Ben. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates 2019-10-23 5:42 ` Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates Michael Ellerman 2019-10-23 6:41 ` Benjamin Herrenschmidt @ 2019-10-23 14:20 ` Christian Zigotzky 2019-11-04 14:44 ` Christian Zigotzky 1 sibling, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2019-10-23 14:20 UTC (permalink / raw) To: Michael Ellerman Cc: ulf.hansson, mad skateman, linux-mmc, Russell King - ARM Linux admin, Rob Herring, Paul Mackerras, R.T.Dickinson, contact, linuxppc-dev, Christian Zigotzky Hello, The patch below works. I compiled the RC4 of kernel 5.4 with this patch today and the onboard SD card works without any problems. Thanks! Christian > On 23. Oct 2019, at 07:42, Michael Ellerman <mpe@ellerman.id.au> wrote: > > Russell King - ARM Linux admin <linux@armlinux.org.uk> writes: >>> On Tue, Oct 15, 2019 at 03:12:49PM +0200, Christian Zigotzky wrote: >>> Hello Russell, >>> >>> You asked me about "dma-coherent" in the Cyrus device tree. Unfortunately I >>> don't find the property "dma-coherent" in the dtb source files. >>> >>> Output of "fdtdump cyrus_p5020_eth_poweroff.dtb | grep dma": >>> >>> dma0 = "/soc@ffe000000/dma@100300"; >>> dma1 = "/soc@ffe000000/dma@101300"; >>> dma@100300 { >>> compatible = "fsl,eloplus-dma"; >>> dma-channel@0 { >>> compatible = "fsl,eloplus-dma-channel"; >>> dma-channel@80 { >>> compatible = "fsl,eloplus-dma-channel"; >>> dma-channel@100 { >>> compatible = "fsl,eloplus-dma-channel"; >>> dma-channel@180 { >>> compatible = "fsl,eloplus-dma-channel"; >>> dma@101300 { >>> compatible = "fsl,eloplus-dma"; >>> dma-channel@0 { >>> compatible = "fsl,eloplus-dma-channel"; >>> dma-channel@80 { >>> compatible = "fsl,eloplus-dma-channel"; >>> dma-channel@100 { >>> compatible = "fsl,eloplus-dma-channel"; >>> dma-channel@180 { >>> compatible = "fsl,eloplus-dma-channel"; >> >> Hmm, so it looks like PowerPC doesn't mark devices that are dma >> coherent with a property that describes them as such. >> >> I think this opens a wider question - what should of_dma_is_coherent() >> return for PowerPC? It seems right now that it returns false for >> devices that are DMA coherent, which seems to me to be a recipe for >> future mistakes. > > Right, it seems of_dma_is_coherent() has baked in the assumption that > devices are non-coherent unless explicitly marked as coherent. > > Which is wrong on all or at least most existing powerpc systems > according to Ben. > >> Any ideas from the PPC maintainers? > > Fixing it at the source seems like the best option to prevent future > breakage. > > So I guess that would mean making of_dma_is_coherent() return true/false > based on CONFIG_NOT_COHERENT_CACHE on powerpc. > > We could do it like below, which would still allow the dma-coherent > property to work if it ever makes sense on a future powerpc platform. > > I don't really know any of this embedded stuff well, so happy to take > other suggestions on how to handle this mess. > > cheers > > > diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c > index 25aaa3903000..b96c9010acb6 100644 > --- a/arch/powerpc/kernel/setup-common.c > +++ b/arch/powerpc/kernel/setup-common.c > @@ -760,6 +760,22 @@ static int __init check_cache_coherency(void) > late_initcall(check_cache_coherency); > #endif /* CONFIG_CHECK_CACHE_COHERENCY */ > > +#ifndef CONFIG_NOT_COHERENT_CACHE > +/* > + * For historical reasons powerpc kernels are built with hard wired knowledge of > + * whether or not DMA accesses are cache coherent. Additionally device trees on > + * powerpc do not typically support the dma-coherent property. > + * > + * So when we know that DMA is coherent, override arch_of_dma_is_coherent() to > + * tell the drivers/of code that all devices are coherent regardless of whether > + * they have a dma-coherent property. > + */ > +bool arch_of_dma_is_coherent(struct device_node *np) > +{ > + return true; > +} > +#endif > + > #ifdef CONFIG_DEBUG_FS > struct dentry *powerpc_debugfs_root; > EXPORT_SYMBOL(powerpc_debugfs_root); > diff --git a/drivers/of/address.c b/drivers/of/address.c > index 978427a9d5e6..3a4b2949a322 100644 > --- a/drivers/of/address.c > +++ b/drivers/of/address.c > @@ -993,6 +993,14 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz > } > EXPORT_SYMBOL_GPL(of_dma_get_range); > > +/* > + * arch_of_dma_is_coherent - Arch hook to determine if device is coherent for DMA > + */ > +bool __weak arch_of_dma_is_coherent(struct device_node *np) > +{ > + return false; > +} > + > /** > * of_dma_is_coherent - Check if device is coherent > * @np: device node > @@ -1002,8 +1010,12 @@ EXPORT_SYMBOL_GPL(of_dma_get_range); > */ > bool of_dma_is_coherent(struct device_node *np) > { > - struct device_node *node = of_node_get(np); > + struct device_node *node; > + > + if (arch_of_dma_is_coherent(np)) > + return true; > > + np = of_node_get(np); > while (node) { > if (of_property_read_bool(node, "dma-coherent")) { > of_node_put(node); ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates 2019-10-23 14:20 ` Christian Zigotzky @ 2019-11-04 14:44 ` Christian Zigotzky 2019-11-05 7:50 ` Bug 205201 - overflow of DMA mask and bus mask Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2019-11-04 14:44 UTC (permalink / raw) To: Michael Ellerman Cc: ulf.hansson, mad skateman, linux-mmc, Russell King - ARM Linux admin, Rob Herring, Paul Mackerras, R.T.Dickinson, contact, linuxppc-dev, Christian Zigotzky FYI: The onboard SD card works also with the RC6 of kernel 5.4 with the patch below. -- Christian On 23 October 2019 at 4:20pm, Christian Zigotzky wrote: > Hello, > > The patch below works. I compiled the RC4 of kernel 5.4 with this patch today and the onboard SD card works without any problems. > > Thanks! > > Christian > >> On 23. Oct 2019, at 07:42, Michael Ellerman <mpe@ellerman.id.au> wrote: >> >> Russell King - ARM Linux admin <linux@armlinux.org.uk> writes: >>>> On Tue, Oct 15, 2019 at 03:12:49PM +0200, Christian Zigotzky wrote: >>>> Hello Russell, >>>> >>>> You asked me about "dma-coherent" in the Cyrus device tree. Unfortunately I >>>> don't find the property "dma-coherent" in the dtb source files. >>>> >>>> Output of "fdtdump cyrus_p5020_eth_poweroff.dtb | grep dma": >>>> >>>> dma0 = "/soc@ffe000000/dma@100300"; >>>> dma1 = "/soc@ffe000000/dma@101300"; >>>> dma@100300 { >>>> compatible = "fsl,eloplus-dma"; >>>> dma-channel@0 { >>>> compatible = "fsl,eloplus-dma-channel"; >>>> dma-channel@80 { >>>> compatible = "fsl,eloplus-dma-channel"; >>>> dma-channel@100 { >>>> compatible = "fsl,eloplus-dma-channel"; >>>> dma-channel@180 { >>>> compatible = "fsl,eloplus-dma-channel"; >>>> dma@101300 { >>>> compatible = "fsl,eloplus-dma"; >>>> dma-channel@0 { >>>> compatible = "fsl,eloplus-dma-channel"; >>>> dma-channel@80 { >>>> compatible = "fsl,eloplus-dma-channel"; >>>> dma-channel@100 { >>>> compatible = "fsl,eloplus-dma-channel"; >>>> dma-channel@180 { >>>> compatible = "fsl,eloplus-dma-channel"; >>> Hmm, so it looks like PowerPC doesn't mark devices that are dma >>> coherent with a property that describes them as such. >>> >>> I think this opens a wider question - what should of_dma_is_coherent() >>> return for PowerPC? It seems right now that it returns false for >>> devices that are DMA coherent, which seems to me to be a recipe for >>> future mistakes. >> Right, it seems of_dma_is_coherent() has baked in the assumption that >> devices are non-coherent unless explicitly marked as coherent. >> >> Which is wrong on all or at least most existing powerpc systems >> according to Ben. >> >>> Any ideas from the PPC maintainers? >> Fixing it at the source seems like the best option to prevent future >> breakage. >> >> So I guess that would mean making of_dma_is_coherent() return true/false >> based on CONFIG_NOT_COHERENT_CACHE on powerpc. >> >> We could do it like below, which would still allow the dma-coherent >> property to work if it ever makes sense on a future powerpc platform. >> >> I don't really know any of this embedded stuff well, so happy to take >> other suggestions on how to handle this mess. >> >> cheers >> >> >> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c >> index 25aaa3903000..b96c9010acb6 100644 >> --- a/arch/powerpc/kernel/setup-common.c >> +++ b/arch/powerpc/kernel/setup-common.c >> @@ -760,6 +760,22 @@ static int __init check_cache_coherency(void) >> late_initcall(check_cache_coherency); >> #endif /* CONFIG_CHECK_CACHE_COHERENCY */ >> >> +#ifndef CONFIG_NOT_COHERENT_CACHE >> +/* >> + * For historical reasons powerpc kernels are built with hard wired knowledge of >> + * whether or not DMA accesses are cache coherent. Additionally device trees on >> + * powerpc do not typically support the dma-coherent property. >> + * >> + * So when we know that DMA is coherent, override arch_of_dma_is_coherent() to >> + * tell the drivers/of code that all devices are coherent regardless of whether >> + * they have a dma-coherent property. >> + */ >> +bool arch_of_dma_is_coherent(struct device_node *np) >> +{ >> + return true; >> +} >> +#endif >> + >> #ifdef CONFIG_DEBUG_FS >> struct dentry *powerpc_debugfs_root; >> EXPORT_SYMBOL(powerpc_debugfs_root); >> diff --git a/drivers/of/address.c b/drivers/of/address.c >> index 978427a9d5e6..3a4b2949a322 100644 >> --- a/drivers/of/address.c >> +++ b/drivers/of/address.c >> @@ -993,6 +993,14 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz >> } >> EXPORT_SYMBOL_GPL(of_dma_get_range); >> >> +/* >> + * arch_of_dma_is_coherent - Arch hook to determine if device is coherent for DMA >> + */ >> +bool __weak arch_of_dma_is_coherent(struct device_node *np) >> +{ >> + return false; >> +} >> + >> /** >> * of_dma_is_coherent - Check if device is coherent >> * @np: device node >> @@ -1002,8 +1010,12 @@ EXPORT_SYMBOL_GPL(of_dma_get_range); >> */ >> bool of_dma_is_coherent(struct device_node *np) >> { >> - struct device_node *node = of_node_get(np); >> + struct device_node *node; >> + >> + if (arch_of_dma_is_coherent(np)) >> + return true; >> >> + np = of_node_get(np); >> while (node) { >> if (of_property_read_bool(node, "dma-coherent")) { >> of_node_put(node); ^ permalink raw reply [flat|nested] 21+ messages in thread
* Bug 205201 - overflow of DMA mask and bus mask 2019-11-04 14:44 ` Christian Zigotzky @ 2019-11-05 7:50 ` Christian Zigotzky 0 siblings, 0 replies; 21+ messages in thread From: Christian Zigotzky @ 2019-11-05 7:50 UTC (permalink / raw) To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras, Darren Stevens, contact, R.T.Dickinson, mad skateman, Rob Herring, linuxppc-dev Hi All, We still have DMA problems with some PCI devices. Since the PowerPC updates 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to work with our PCI devices. The FSL P5020 and P5040 have these problems currently. Error message: [ 25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096 of DMA mask ffffffff bus mask df000000 All 5.x Linux kernels can't initialize a SCSI PCI card anymore so booting of a Linux userland isn't possible. PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The kernel 4.20 works with all PCI devices without limitation of RAM. We created a bug report a month ago. [2] Thanks, Christian [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6973327ee84c2f40dd9efd8928d4a1186c96e2 [2] https://bugzilla.kernel.org/show_bug.cgi?id=205201 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: use generic DMA mapping code in powerpc V4 @ 2018-12-13 11:25 Christoph Hellwig 2018-12-13 13:34 ` Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christoph Hellwig @ 2018-12-13 11:25 UTC (permalink / raw) To: Christian Zigotzky Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson, linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev, Christoph Hellwig On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote: > I tried it again but I get the following error message: > > MODPOST vmlinux.o > arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask': > (.text+0x274): undefined reference to `.dma_direct_get_required_mask' > make: *** [vmlinux] Error 1 Sorry, you need this one liner before all the patches posted last time: diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index d8819e3a1eb1..7e78c2798f2f 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -154,6 +154,7 @@ config PPC select CLONE_BACKWARDS select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN select DYNAMIC_FTRACE if FUNCTION_TRACER + select DMA_DIRECT_OPS select EDAC_ATOMIC_SCRUB select EDAC_SUPPORT select GENERIC_ATOMIC64 if PPC32 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: use generic DMA mapping code in powerpc V4 2018-12-13 11:25 use generic DMA mapping code in powerpc V4 Christoph Hellwig @ 2018-12-13 13:34 ` Christian Zigotzky 2018-12-13 17:48 ` Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2018-12-13 13:34 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson, linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev On 13 December 2018 at 12:25PM, Christoph Hellwig wrote: > On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote: >> I tried it again but I get the following error message: >> >> MODPOST vmlinux.o >> arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask': >> (.text+0x274): undefined reference to `.dma_direct_get_required_mask' >> make: *** [vmlinux] Error 1 > Sorry, you need this one liner before all the patches posted last time: > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index d8819e3a1eb1..7e78c2798f2f 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -154,6 +154,7 @@ config PPC > select CLONE_BACKWARDS > select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN > select DYNAMIC_FTRACE if FUNCTION_TRACER > + select DMA_DIRECT_OPS > select EDAC_ATOMIC_SCRUB > select EDAC_SUPPORT > select GENERIC_ATOMIC64 if PPC32 > Thanks. Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots with the patch '0001-get_required_mask.patch'. -- Christian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: use generic DMA mapping code in powerpc V4 2018-12-13 13:34 ` Christian Zigotzky @ 2018-12-13 17:48 ` Christian Zigotzky 2018-12-13 21:53 ` Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2018-12-13 17:48 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson, linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev On 13 December 2018 at 2:34PM, Christian Zigotzky wrote: > On 13 December 2018 at 12:25PM, Christoph Hellwig wrote: >> On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote: >>> I tried it again but I get the following error message: >>> >>> MODPOST vmlinux.o >>> arch/powerpc/kernel/dma-iommu.o: In function >>> `.dma_iommu_get_required_mask': >>> (.text+0x274): undefined reference to `.dma_direct_get_required_mask' >>> make: *** [vmlinux] Error 1 >> Sorry, you need this one liner before all the patches posted last time: >> >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >> index d8819e3a1eb1..7e78c2798f2f 100644 >> --- a/arch/powerpc/Kconfig >> +++ b/arch/powerpc/Kconfig >> @@ -154,6 +154,7 @@ config PPC >> select CLONE_BACKWARDS >> select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN >> select DYNAMIC_FTRACE if FUNCTION_TRACER >> + select DMA_DIRECT_OPS >> select EDAC_ATOMIC_SCRUB >> select EDAC_SUPPORT >> select GENERIC_ATOMIC64 if PPC32 >> > Thanks. Result: PASEMI onboard ethernet works and the X5000 (P5020 > board) boots with the patch '0001-get_required_mask.patch'. > > -- Christian > > Next patch: '0002-swiotlb-dma_supported.patch' for the last good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). The PASEMI onboard ethernet works and the X5000 (P5020 board) boots. -- Christian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: use generic DMA mapping code in powerpc V4 2018-12-13 17:48 ` Christian Zigotzky @ 2018-12-13 21:53 ` Christian Zigotzky 2018-12-14 12:00 ` Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2018-12-13 21:53 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson, linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev On 13 December 2018 at 6:48PM, Christian Zigotzky wrote: > On 13 December 2018 at 2:34PM, Christian Zigotzky wrote: >> On 13 December 2018 at 12:25PM, Christoph Hellwig wrote: >>> On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote: >>>> I tried it again but I get the following error message: >>>> >>>> MODPOST vmlinux.o >>>> arch/powerpc/kernel/dma-iommu.o: In function >>>> `.dma_iommu_get_required_mask': >>>> (.text+0x274): undefined reference to `.dma_direct_get_required_mask' >>>> make: *** [vmlinux] Error 1 >>> Sorry, you need this one liner before all the patches posted last time: >>> >>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >>> index d8819e3a1eb1..7e78c2798f2f 100644 >>> --- a/arch/powerpc/Kconfig >>> +++ b/arch/powerpc/Kconfig >>> @@ -154,6 +154,7 @@ config PPC >>> select CLONE_BACKWARDS >>> select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN >>> select DYNAMIC_FTRACE if FUNCTION_TRACER >>> + select DMA_DIRECT_OPS >>> select EDAC_ATOMIC_SCRUB >>> select EDAC_SUPPORT >>> select GENERIC_ATOMIC64 if PPC32 >>> >> Thanks. Result: PASEMI onboard ethernet works and the X5000 (P5020 >> board) boots with the patch '0001-get_required_mask.patch'. >> >> -- Christian >> >> > Next patch: '0002-swiotlb-dma_supported.patch' for the last good > commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). > > The PASEMI onboard ethernet works and the X5000 (P5020 board) boots. > > -- Christian > > Next patch: '0003-nommu-dma_supported.patch' No problems with the PASEMI onboard ethernet and the P5020 board boots. -- Christian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: use generic DMA mapping code in powerpc V4 2018-12-13 21:53 ` Christian Zigotzky @ 2018-12-14 12:00 ` Christian Zigotzky 2019-01-03 7:36 ` Christoph Hellwig 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2018-12-14 12:00 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson, linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev On 12 December 2018 at 3:15PM, Christoph Hellwig wrote: > Thanks for bisecting. I've spent some time going over the conversion > but can't really pinpoint it. I have three little patches that switch > parts of the code to the generic version. This is on top of the > last good commmit (977706f9755d2d697aa6f45b4f9f0e07516efeda). > > Can you check with whіch one things stop working? Hello Christoph, Great news! All your patches work! I tested all your patches (including the patch '0004-alloc-free.patch' today) and the PASEMI onboard ethernet works and the P5020 board boots without any problems. Thank you for your work! I have a few days off. That means, I will work less and only for the A-EON first level Linux support. I can test again on Thursday next week. Have a nice weekend! Cheers, Christian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: use generic DMA mapping code in powerpc V4 2018-12-14 12:00 ` Christian Zigotzky @ 2019-01-03 7:36 ` Christoph Hellwig 2019-01-03 19:26 ` Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christoph Hellwig @ 2019-01-03 7:36 UTC (permalink / raw) To: Christian Zigotzky Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson, linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev, Christoph Hellwig Hi Christian, happy new year and I hope you had a few restful deays off. I've pushed a new tree to: git://git.infradead.org/users/hch/misc.git powerpc-dma.6 Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Which has been rebased to the latests Linus tree, which has a lot of changes, and has also changed the patch split a bit to aid bisection. I think http://git.infradead.org/users/hch/misc.git/commitdiff/c446404b041130fbd9d1772d184f24715cf2362f might be a good commit to re-start testing, then bisecting up to the last commit using git bisect. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: use generic DMA mapping code in powerpc V4 2019-01-03 7:36 ` Christoph Hellwig @ 2019-01-03 19:26 ` Christian Zigotzky 2019-01-05 16:03 ` Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2019-01-03 19:26 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson, linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev Hi Christoph, Happy new year for you too. Unfortunately we have some problems with the latest DRM patches. They modified a lot and some graphics cards don’t work anymore. During the holidays we tried to figure out where the problems are but without any success. I will try to test your patches next week. Cheers, Christian Sent from my iPhone > On 3. Jan 2019, at 08:36, Christoph Hellwig <hch@lst.de> wrote: > > Hi Christian, > > happy new year and I hope you had a few restful deays off. > > I've pushed a new tree to: > > git://git.infradead.org/users/hch/misc.git powerpc-dma.6 > > Gitweb: > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 > > Which has been rebased to the latests Linus tree, which has a lot of > changes, and has also changed the patch split a bit to aid bisection. > > I think > > http://git.infradead.org/users/hch/misc.git/commitdiff/c446404b041130fbd9d1772d184f24715cf2362f > > might be a good commit to re-start testing, then bisecting up to the > last commit using git bisect. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: use generic DMA mapping code in powerpc V4 2019-01-03 19:26 ` Christian Zigotzky @ 2019-01-05 16:03 ` Christian Zigotzky 2019-01-09 9:31 ` Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2019-01-05 16:03 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson, linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma: remove dma_nommu_mmap_coherent) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout c446404b041130fbd9d1772d184f24715cf2362f Output: Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent ----- Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. -- Christian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: use generic DMA mapping code in powerpc V4 2019-01-05 16:03 ` Christian Zigotzky @ 2019-01-09 9:31 ` Christian Zigotzky [not found] ` <46025f1b-db20-ac23-7dcd-10bc43bbb6ee@xenosoft.de> 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2019-01-09 9:31 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson, linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma: remove dma_nommu_get_required_mask) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout a64e18ba191ba9102fb174f27d707485ffd9389c Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 05 January 2019 at 5:03PM, Christian Zigotzky wrote: > Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma: > remove dma_nommu_mmap_coherent) > > git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a > > git checkout c446404b041130fbd9d1772d184f24715cf2362f > > Output: > > Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'. > > You are in 'detached HEAD' state. You can look around, make experimental > changes and commit them, and you can discard any commits you make in this > state without impacting any branches by performing another checkout. > > If you want to create a new branch to retain commits you create, you may > do so (now or later) by using -b with the checkout command again. > Example: > > git checkout -b <new-branch-name> > > HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent > > ----- > > Link to the Git: > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 > > Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. > > -- Christian > ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <46025f1b-db20-ac23-7dcd-10bc43bbb6ee@xenosoft.de>]
[parent not found: <20191105162856.GA15402@lst.de>]
* Re: Bug 205201 - overflow of DMA mask and bus mask [not found] ` <20191105162856.GA15402@lst.de> @ 2019-11-07 9:53 ` Christian Zigotzky 2019-11-10 7:27 ` Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2019-11-07 9:53 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, darren, mad skateman, linux-kernel, linux-mm, iommu, Rob Herring, paulus, rtd2, contact, linuxppc-dev On 05 November 2019 at 5:28 pm, Christoph Hellwig wrote: > On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote: >> Hi All, >> >> We still have DMA problems with some PCI devices. Since the PowerPC updates >> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to >> work with our PCI devices. The FSL P5020 and P5040 have these problems >> currently. >> >> Error message: >> >> [ 25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096 of DMA >> mask ffffffff bus mask df000000 >> >> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so booting >> of a Linux userland isn't possible. >> >> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The kernel >> 4.20 works with all PCI devices without limitation of RAM. > Can you send me the .config and a dmesg? And in the meantime try the > patch below? > > --- > >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 2001 > From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > Date: Fri, 18 Oct 2019 13:00:43 +0200 > Subject: dma-direct: check for overflows on 32 bit DMA addresses > > As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is > possible for a device configured with 32 bit DMA addresses and a partial > DMA mapping located at the end of the address space to overflow. It > happens when a higher physical address, not DMAable, is translated to > it's DMA counterpart. > > For example the Raspberry Pi 4, configurable up to 4 GB of memory, has > an interconnect capable of addressing the lower 1 GB of physical memory > with a DMA offset of 0xc0000000. It transpires that, any attempt to > translate physical addresses higher than the first GB will result in an > overflow which dma_capable() can't detect as it only checks for > addresses bigger then the maximum allowed DMA address. > > Fix this by verifying in dma_capable() if the DMA address range provided > is at any point lower than the minimum possible DMA address on the bus. > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > --- > include/linux/dma-direct.h | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h > index adf993a3bd58..6ad9e9ea7564 100644 > --- a/include/linux/dma-direct.h > +++ b/include/linux/dma-direct.h > @@ -3,6 +3,7 @@ > #define _LINUX_DMA_DIRECT_H 1 > > #include <linux/dma-mapping.h> > +#include <linux/memblock.h> /* for min_low_pfn */ > #include <linux/mem_encrypt.h> > > #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA > @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size) > if (!dev->dma_mask) > return false; > > +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT > + /* Check if DMA address overflowed */ > + if (min(addr, addr + size - 1) < > + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) > + return false; > +#endif > + > return addr + size - 1 <= > min_not_zero(*dev->dma_mask, dev->bus_dma_mask); > } Hello Christoph, Thanks a lot for your patch! Unfortunately this patch doesn't solve the issue. Error messages: [ 6.041163] bttv: driver version 0.9.19 loaded [ 6.041167] bttv: using 8 buffers with 2080k (520 pages) each for capture [ 6.041559] bttv: Bt8xx card found (0) [ 6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19, latency: 128, mmio: 0xc20001000 [ 6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1 TV Station RDS [card=53,insmod option] [ 6.042216] bttv: 0: tuner type=5 [ 6.111994] bttv: 0: audio absent, no audio device found! [ 6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up to 100ms) [ 6.200005] bttv: PLL set ok [ 6.209351] bttv: 0: registered device video0 [ 6.211576] bttv: 0: registered device vbi0 [ 6.214897] bttv: 0: registered device radio0 [ 114.218806] bttv 1000:04:05.0: overflow 0x00000000ff507000+4096 of DMA mask ffffffff bus mask df000000 [ 114.218848] Modules linked in: rfcomm bnep tuner_simple tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc btusb btrtl btbcm btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc [ 114.219012] [c0000001ecddf720] [80000000008ff6e8] .buffer_prepare+0x150/0x268 [bttv] [ 114.219029] [c0000001ecddf860] [80000000008fff6c] .bttv_qbuf+0x50/0x64 [bttv] ----- Trace: [ 462.783184] Call Trace: [ 462.783187] [c0000001c6c67420] [c0000000000b3358] .report_addr+0xb8/0xc0 (unreliable) [ 462.783192] [c0000001c6c67490] [c0000000000b351c] .dma_direct_map_page+0xf0/0x128 [ 462.783195] [c0000001c6c67530] [c0000000000b35b0] .dma_direct_map_sg+0x5c/0xac [ 462.783205] [c0000001c6c675e0] [8000000000862e88] .__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg] [ 462.783220] [c0000001c6c676b0] [8000000000854274] .videobuf_iolock+0x98/0xb4 [videobuf_core] [ 462.783271] [c0000001c6c67720] [80000000008686e8] .buffer_prepare+0x150/0x268 [bttv] [ 462.783276] [c0000001c6c677c0] [8000000000854afc] .videobuf_qbuf+0x2b8/0x428 [videobuf_core] [ 462.783288] [c0000001c6c67860] [8000000000868f6c] .bttv_qbuf+0x50/0x64 [bttv] [ 462.783383] [c0000001c6c678e0] [80000000007bf208] .v4l_qbuf+0x54/0x60 [videodev] [ 462.783402] [c0000001c6c67970] [80000000007c1eac] .__video_do_ioctl+0x30c/0x3f8 [videodev] [ 462.783421] [c0000001c6c67a80] [80000000007c3c08] .video_usercopy+0x18c/0x3dc [videodev] [ 462.783440] [c0000001c6c67c00] [80000000007bb14c] .v4l2_ioctl+0x60/0x78 [videodev] [ 462.783460] [c0000001c6c67c90] [80000000007d3c48] .v4l2_compat_ioctl32+0x9b4/0x1850 [videodev] [ 462.783468] [c0000001c6c67d70] [c0000000001ad9cc] .__se_compat_sys_ioctl+0x284/0x127c [ 462.783473] [c0000001c6c67e20] [c00000000000067c] system_call+0x60/0x6c [ 462.783475] Instruction dump: [ 462.783477] 40fe0044 60000000 892255d0 2f890000 40fe0020 3c82ffc5 39200001 60000000 [ 462.783483] 38842029 992255d0 485ad0d9 60000000 <0fe00000> 38210070 e8010010 7c0803a6 [ 462.783490] ---[ end trace b677d4a00458e277 ]--- ----- dmesg fsl p5040: https://bugzilla.kernel.org/attachment.cgi?id=285813 Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500 board (CPU: P5040 and P5020): https://bugzilla.kernel.org/attachment.cgi?id=285815 Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=205201 Thanks for your help, Christian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug 205201 - overflow of DMA mask and bus mask 2019-11-07 9:53 ` Bug 205201 - overflow of DMA mask and bus mask Christian Zigotzky @ 2019-11-10 7:27 ` Christian Zigotzky 2019-11-11 8:12 ` Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2019-11-10 7:27 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, darren, mad skateman, linux-kernel, linux-mm, iommu, Rob Herring, paulus, rtd2, contact, linuxppc-dev On 07 November 2019 at 10:53 am, Christian Zigotzky wrote: > On 05 November 2019 at 5:28 pm, Christoph Hellwig wrote: >> On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote: >>> Hi All, >>> >>> We still have DMA problems with some PCI devices. Since the PowerPC >>> updates >>> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we >>> want to >>> work with our PCI devices. The FSL P5020 and P5040 have these problems >>> currently. >>> >>> Error message: >>> >>> [ 25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096 >>> of DMA >>> mask ffffffff bus mask df000000 >>> >>> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so >>> booting >>> of a Linux userland isn't possible. >>> >>> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The >>> kernel >>> 4.20 works with all PCI devices without limitation of RAM. >> Can you send me the .config and a dmesg? And in the meantime try the >> patch below? >> >> --- >> >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 2001 >> From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >> Date: Fri, 18 Oct 2019 13:00:43 +0200 >> Subject: dma-direct: check for overflows on 32 bit DMA addresses >> >> As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is >> possible for a device configured with 32 bit DMA addresses and a partial >> DMA mapping located at the end of the address space to overflow. It >> happens when a higher physical address, not DMAable, is translated to >> it's DMA counterpart. >> >> For example the Raspberry Pi 4, configurable up to 4 GB of memory, has >> an interconnect capable of addressing the lower 1 GB of physical memory >> with a DMA offset of 0xc0000000. It transpires that, any attempt to >> translate physical addresses higher than the first GB will result in an >> overflow which dma_capable() can't detect as it only checks for >> addresses bigger then the maximum allowed DMA address. >> >> Fix this by verifying in dma_capable() if the DMA address range provided >> is at any point lower than the minimum possible DMA address on the bus. >> >> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >> --- >> include/linux/dma-direct.h | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h >> index adf993a3bd58..6ad9e9ea7564 100644 >> --- a/include/linux/dma-direct.h >> +++ b/include/linux/dma-direct.h >> @@ -3,6 +3,7 @@ >> #define _LINUX_DMA_DIRECT_H 1 >> #include <linux/dma-mapping.h> >> +#include <linux/memblock.h> /* for min_low_pfn */ >> #include <linux/mem_encrypt.h> >> #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA >> @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device *dev, >> dma_addr_t addr, size_t size) >> if (!dev->dma_mask) >> return false; >> +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT >> + /* Check if DMA address overflowed */ >> + if (min(addr, addr + size - 1) < >> + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) >> + return false; >> +#endif >> + >> return addr + size - 1 <= >> min_not_zero(*dev->dma_mask, dev->bus_dma_mask); >> } > Hello Christoph, > > Thanks a lot for your patch! Unfortunately this patch doesn't solve > the issue. > > Error messages: > > [ 6.041163] bttv: driver version 0.9.19 loaded > [ 6.041167] bttv: using 8 buffers with 2080k (520 pages) each for > capture > [ 6.041559] bttv: Bt8xx card found (0) > [ 6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19, > latency: 128, mmio: 0xc20001000 > [ 6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1 TV > Station RDS [card=53,insmod option] > [ 6.042216] bttv: 0: tuner type=5 > [ 6.111994] bttv: 0: audio absent, no audio device found! > [ 6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up to > 100ms) > [ 6.200005] bttv: PLL set ok > [ 6.209351] bttv: 0: registered device video0 > [ 6.211576] bttv: 0: registered device vbi0 > [ 6.214897] bttv: 0: registered device radio0 > [ 114.218806] bttv 1000:04:05.0: overflow 0x00000000ff507000+4096 of > DMA mask ffffffff bus mask df000000 > [ 114.218848] Modules linked in: rfcomm bnep tuner_simple tuner_types > tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x tveeprom > videobuf_dma_sg videobuf_core rc_core videodev mc btusb btrtl btbcm > btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc > [ 114.219012] [c0000001ecddf720] [80000000008ff6e8] > .buffer_prepare+0x150/0x268 [bttv] > [ 114.219029] [c0000001ecddf860] [80000000008fff6c] > .bttv_qbuf+0x50/0x64 [bttv] > > ----- > > Trace: > > [ 462.783184] Call Trace: > [ 462.783187] [c0000001c6c67420] [c0000000000b3358] > .report_addr+0xb8/0xc0 (unreliable) > [ 462.783192] [c0000001c6c67490] [c0000000000b351c] > .dma_direct_map_page+0xf0/0x128 > [ 462.783195] [c0000001c6c67530] [c0000000000b35b0] > .dma_direct_map_sg+0x5c/0xac > [ 462.783205] [c0000001c6c675e0] [8000000000862e88] > .__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg] > [ 462.783220] [c0000001c6c676b0] [8000000000854274] > .videobuf_iolock+0x98/0xb4 [videobuf_core] > [ 462.783271] [c0000001c6c67720] [80000000008686e8] > .buffer_prepare+0x150/0x268 [bttv] > [ 462.783276] [c0000001c6c677c0] [8000000000854afc] > .videobuf_qbuf+0x2b8/0x428 [videobuf_core] > [ 462.783288] [c0000001c6c67860] [8000000000868f6c] > .bttv_qbuf+0x50/0x64 [bttv] > [ 462.783383] [c0000001c6c678e0] [80000000007bf208] > .v4l_qbuf+0x54/0x60 [videodev] > [ 462.783402] [c0000001c6c67970] [80000000007c1eac] > .__video_do_ioctl+0x30c/0x3f8 [videodev] > [ 462.783421] [c0000001c6c67a80] [80000000007c3c08] > .video_usercopy+0x18c/0x3dc [videodev] > [ 462.783440] [c0000001c6c67c00] [80000000007bb14c] > .v4l2_ioctl+0x60/0x78 [videodev] > [ 462.783460] [c0000001c6c67c90] [80000000007d3c48] > .v4l2_compat_ioctl32+0x9b4/0x1850 [videodev] > [ 462.783468] [c0000001c6c67d70] [c0000000001ad9cc] > .__se_compat_sys_ioctl+0x284/0x127c > [ 462.783473] [c0000001c6c67e20] [c00000000000067c] > system_call+0x60/0x6c > [ 462.783475] Instruction dump: > [ 462.783477] 40fe0044 60000000 892255d0 2f890000 40fe0020 3c82ffc5 > 39200001 60000000 > [ 462.783483] 38842029 992255d0 485ad0d9 60000000 <0fe00000> 38210070 > e8010010 7c0803a6 > [ 462.783490] ---[ end trace b677d4a00458e277 ]--- > > ----- > > dmesg fsl p5040: https://bugzilla.kernel.org/attachment.cgi?id=285813 > > Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500 > board (CPU: P5040 and P5020): > https://bugzilla.kernel.org/attachment.cgi?id=285815 > > Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=205201 > > Thanks for your help, > > Christian Christoph, Do you have another patch for testing or shall I bisect? Thanks, Christian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug 205201 - overflow of DMA mask and bus mask 2019-11-10 7:27 ` Christian Zigotzky @ 2019-11-11 8:12 ` Christian Zigotzky 2019-11-11 8:16 ` Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2019-11-11 8:12 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, darren, mad skateman, linux-kernel, linux-mm, iommu, Rob Herring, paulus, rtd2, contact, linuxppc-dev On 10 November 2019 at 08:27 am, Christian Zigotzky wrote: > On 07 November 2019 at 10:53 am, Christian Zigotzky wrote: >> On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote: >>> On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote: >>>> Hi All, >>>> >>>> We still have DMA problems with some PCI devices. Since the PowerPC >>>> updates >>>> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we >>>> want to >>>> work with our PCI devices. The FSL P5020 and P5040 have these problems >>>> currently. >>>> >>>> Error message: >>>> >>>> [ 25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096 >>>> of DMA >>>> mask ffffffff bus mask df000000 >>>> >>>> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so >>>> booting >>>> of a Linux userland isn't possible. >>>> >>>> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The >>>> kernel >>>> 4.20 works with all PCI devices without limitation of RAM. >>> Can you send me the .config and a dmesg? And in the meantime try the >>> patch below? >>> >>> --- >>> >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 2001 >>> From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >>> Date: Fri, 18 Oct 2019 13:00:43 +0200 >>> Subject: dma-direct: check for overflows on 32 bit DMA addresses >>> >>> As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation >>> it is >>> possible for a device configured with 32 bit DMA addresses and a >>> partial >>> DMA mapping located at the end of the address space to overflow. It >>> happens when a higher physical address, not DMAable, is translated to >>> it's DMA counterpart. >>> >>> For example the Raspberry Pi 4, configurable up to 4 GB of memory, has >>> an interconnect capable of addressing the lower 1 GB of physical memory >>> with a DMA offset of 0xc0000000. It transpires that, any attempt to >>> translate physical addresses higher than the first GB will result in an >>> overflow which dma_capable() can't detect as it only checks for >>> addresses bigger then the maximum allowed DMA address. >>> >>> Fix this by verifying in dma_capable() if the DMA address range >>> provided >>> is at any point lower than the minimum possible DMA address on the bus. >>> >>> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >>> --- >>> include/linux/dma-direct.h | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h >>> index adf993a3bd58..6ad9e9ea7564 100644 >>> --- a/include/linux/dma-direct.h >>> +++ b/include/linux/dma-direct.h >>> @@ -3,6 +3,7 @@ >>> #define _LINUX_DMA_DIRECT_H 1 >>> #include <linux/dma-mapping.h> >>> +#include <linux/memblock.h> /* for min_low_pfn */ >>> #include <linux/mem_encrypt.h> >>> #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA >>> @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device >>> *dev, dma_addr_t addr, size_t size) >>> if (!dev->dma_mask) >>> return false; >>> +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT >>> + /* Check if DMA address overflowed */ >>> + if (min(addr, addr + size - 1) < >>> + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) >>> + return false; >>> +#endif >>> + >>> return addr + size - 1 <= >>> min_not_zero(*dev->dma_mask, dev->bus_dma_mask); >>> } >> Hello Christoph, >> >> Thanks a lot for your patch! Unfortunately this patch doesn't solve >> the issue. >> >> Error messages: >> >> [ 6.041163] bttv: driver version 0.9.19 loaded >> [ 6.041167] bttv: using 8 buffers with 2080k (520 pages) each for >> capture >> [ 6.041559] bttv: Bt8xx card found (0) >> [ 6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19, >> latency: 128, mmio: 0xc20001000 >> [ 6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1 >> TV Station RDS [card=53,insmod option] >> [ 6.042216] bttv: 0: tuner type=5 >> [ 6.111994] bttv: 0: audio absent, no audio device found! >> [ 6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up >> to 100ms) >> [ 6.200005] bttv: PLL set ok >> [ 6.209351] bttv: 0: registered device video0 >> [ 6.211576] bttv: 0: registered device vbi0 >> [ 6.214897] bttv: 0: registered device radio0 >> [ 114.218806] bttv 1000:04:05.0: overflow 0x00000000ff507000+4096 of >> DMA mask ffffffff bus mask df000000 >> [ 114.218848] Modules linked in: rfcomm bnep tuner_simple >> tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x >> tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc btusb >> btrtl btbcm btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc >> [ 114.219012] [c0000001ecddf720] [80000000008ff6e8] >> .buffer_prepare+0x150/0x268 [bttv] >> [ 114.219029] [c0000001ecddf860] [80000000008fff6c] >> .bttv_qbuf+0x50/0x64 [bttv] >> >> ----- >> >> Trace: >> >> [ 462.783184] Call Trace: >> [ 462.783187] [c0000001c6c67420] [c0000000000b3358] >> .report_addr+0xb8/0xc0 (unreliable) >> [ 462.783192] [c0000001c6c67490] [c0000000000b351c] >> .dma_direct_map_page+0xf0/0x128 >> [ 462.783195] [c0000001c6c67530] [c0000000000b35b0] >> .dma_direct_map_sg+0x5c/0xac >> [ 462.783205] [c0000001c6c675e0] [8000000000862e88] >> .__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg] >> [ 462.783220] [c0000001c6c676b0] [8000000000854274] >> .videobuf_iolock+0x98/0xb4 [videobuf_core] >> [ 462.783271] [c0000001c6c67720] [80000000008686e8] >> .buffer_prepare+0x150/0x268 [bttv] >> [ 462.783276] [c0000001c6c677c0] [8000000000854afc] >> .videobuf_qbuf+0x2b8/0x428 [videobuf_core] >> [ 462.783288] [c0000001c6c67860] [8000000000868f6c] >> .bttv_qbuf+0x50/0x64 [bttv] >> [ 462.783383] [c0000001c6c678e0] [80000000007bf208] >> .v4l_qbuf+0x54/0x60 [videodev] >> [ 462.783402] [c0000001c6c67970] [80000000007c1eac] >> .__video_do_ioctl+0x30c/0x3f8 [videodev] >> [ 462.783421] [c0000001c6c67a80] [80000000007c3c08] >> .video_usercopy+0x18c/0x3dc [videodev] >> [ 462.783440] [c0000001c6c67c00] [80000000007bb14c] >> .v4l2_ioctl+0x60/0x78 [videodev] >> [ 462.783460] [c0000001c6c67c90] [80000000007d3c48] >> .v4l2_compat_ioctl32+0x9b4/0x1850 [videodev] >> [ 462.783468] [c0000001c6c67d70] [c0000000001ad9cc] >> .__se_compat_sys_ioctl+0x284/0x127c >> [ 462.783473] [c0000001c6c67e20] [c00000000000067c] >> system_call+0x60/0x6c >> [ 462.783475] Instruction dump: >> [ 462.783477] 40fe0044 60000000 892255d0 2f890000 40fe0020 3c82ffc5 >> 39200001 60000000 >> [ 462.783483] 38842029 992255d0 485ad0d9 60000000 <0fe00000> >> 38210070 e8010010 7c0803a6 >> [ 462.783490] ---[ end trace b677d4a00458e277 ]--- >> >> ----- >> >> dmesg fsl p5040: https://bugzilla.kernel.org/attachment.cgi?id=285813 >> >> Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500 >> board (CPU: P5040 and P5020): >> https://bugzilla.kernel.org/attachment.cgi?id=285815 >> >> Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=205201 >> >> Thanks for your help, >> >> Christian > > Christoph, > > Do you have another patch for testing or shall I bisect? > > Thanks, > Christian Hi Christoph, I have seen that I have activated the kernel config option CONFIG_ARCH_DMA_ADDR_T_64BIT. That means your code in your patch won't work if this kernel option is enabled. +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT + /* Check if DMA address overflowed */ + if (min(addr, addr + size - 1) < + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) + return false; +#endif I will delete the lines with ifndef and endif and will try it again. Cheers, Christian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug 205201 - overflow of DMA mask and bus mask 2019-11-11 8:12 ` Christian Zigotzky @ 2019-11-11 8:16 ` Christian Zigotzky 2019-11-11 12:22 ` Christian Zigotzky 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2019-11-11 8:16 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, darren, mad skateman, linux-kernel, linux-mm, iommu, Rob Herring, paulus, rtd2, contact, linuxppc-dev On 11 November 2019 at 09:12 am, Christian Zigotzky wrote: > On 10 November 2019 at 08:27 am, Christian Zigotzky wrote: >> On 07 November 2019 at 10:53 am, Christian Zigotzky wrote: >>> On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote: >>>> On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote: >>>>> Hi All, >>>>> >>>>> We still have DMA problems with some PCI devices. Since the >>>>> PowerPC updates >>>>> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we >>>>> want to >>>>> work with our PCI devices. The FSL P5020 and P5040 have these >>>>> problems >>>>> currently. >>>>> >>>>> Error message: >>>>> >>>>> [ 25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096 >>>>> of DMA >>>>> mask ffffffff bus mask df000000 >>>>> >>>>> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so >>>>> booting >>>>> of a Linux userland isn't possible. >>>>> >>>>> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. >>>>> The kernel >>>>> 4.20 works with all PCI devices without limitation of RAM. >>>> Can you send me the .config and a dmesg? And in the meantime try the >>>> patch below? >>>> >>>> --- >>>> >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 >>>> 2001 >>>> From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >>>> Date: Fri, 18 Oct 2019 13:00:43 +0200 >>>> Subject: dma-direct: check for overflows on 32 bit DMA addresses >>>> >>>> As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation >>>> it is >>>> possible for a device configured with 32 bit DMA addresses and a >>>> partial >>>> DMA mapping located at the end of the address space to overflow. It >>>> happens when a higher physical address, not DMAable, is translated to >>>> it's DMA counterpart. >>>> >>>> For example the Raspberry Pi 4, configurable up to 4 GB of memory, has >>>> an interconnect capable of addressing the lower 1 GB of physical >>>> memory >>>> with a DMA offset of 0xc0000000. It transpires that, any attempt to >>>> translate physical addresses higher than the first GB will result >>>> in an >>>> overflow which dma_capable() can't detect as it only checks for >>>> addresses bigger then the maximum allowed DMA address. >>>> >>>> Fix this by verifying in dma_capable() if the DMA address range >>>> provided >>>> is at any point lower than the minimum possible DMA address on the >>>> bus. >>>> >>>> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >>>> --- >>>> include/linux/dma-direct.h | 8 ++++++++ >>>> 1 file changed, 8 insertions(+) >>>> >>>> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h >>>> index adf993a3bd58..6ad9e9ea7564 100644 >>>> --- a/include/linux/dma-direct.h >>>> +++ b/include/linux/dma-direct.h >>>> @@ -3,6 +3,7 @@ >>>> #define _LINUX_DMA_DIRECT_H 1 >>>> #include <linux/dma-mapping.h> >>>> +#include <linux/memblock.h> /* for min_low_pfn */ >>>> #include <linux/mem_encrypt.h> >>>> #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA >>>> @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device >>>> *dev, dma_addr_t addr, size_t size) >>>> if (!dev->dma_mask) >>>> return false; >>>> +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT >>>> + /* Check if DMA address overflowed */ >>>> + if (min(addr, addr + size - 1) < >>>> + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) >>>> + return false; >>>> +#endif >>>> + >>>> return addr + size - 1 <= >>>> min_not_zero(*dev->dma_mask, dev->bus_dma_mask); >>>> } >>> Hello Christoph, >>> >>> Thanks a lot for your patch! Unfortunately this patch doesn't solve >>> the issue. >>> >>> Error messages: >>> >>> [ 6.041163] bttv: driver version 0.9.19 loaded >>> [ 6.041167] bttv: using 8 buffers with 2080k (520 pages) each for >>> capture >>> [ 6.041559] bttv: Bt8xx card found (0) >>> [ 6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19, >>> latency: 128, mmio: 0xc20001000 >>> [ 6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1 >>> TV Station RDS [card=53,insmod option] >>> [ 6.042216] bttv: 0: tuner type=5 >>> [ 6.111994] bttv: 0: audio absent, no audio device found! >>> [ 6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up >>> to 100ms) >>> [ 6.200005] bttv: PLL set ok >>> [ 6.209351] bttv: 0: registered device video0 >>> [ 6.211576] bttv: 0: registered device vbi0 >>> [ 6.214897] bttv: 0: registered device radio0 >>> [ 114.218806] bttv 1000:04:05.0: overflow 0x00000000ff507000+4096 >>> of DMA mask ffffffff bus mask df000000 >>> [ 114.218848] Modules linked in: rfcomm bnep tuner_simple >>> tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x >>> tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc btusb >>> btrtl btbcm btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc >>> [ 114.219012] [c0000001ecddf720] [80000000008ff6e8] >>> .buffer_prepare+0x150/0x268 [bttv] >>> [ 114.219029] [c0000001ecddf860] [80000000008fff6c] >>> .bttv_qbuf+0x50/0x64 [bttv] >>> >>> ----- >>> >>> Trace: >>> >>> [ 462.783184] Call Trace: >>> [ 462.783187] [c0000001c6c67420] [c0000000000b3358] >>> .report_addr+0xb8/0xc0 (unreliable) >>> [ 462.783192] [c0000001c6c67490] [c0000000000b351c] >>> .dma_direct_map_page+0xf0/0x128 >>> [ 462.783195] [c0000001c6c67530] [c0000000000b35b0] >>> .dma_direct_map_sg+0x5c/0xac >>> [ 462.783205] [c0000001c6c675e0] [8000000000862e88] >>> .__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg] >>> [ 462.783220] [c0000001c6c676b0] [8000000000854274] >>> .videobuf_iolock+0x98/0xb4 [videobuf_core] >>> [ 462.783271] [c0000001c6c67720] [80000000008686e8] >>> .buffer_prepare+0x150/0x268 [bttv] >>> [ 462.783276] [c0000001c6c677c0] [8000000000854afc] >>> .videobuf_qbuf+0x2b8/0x428 [videobuf_core] >>> [ 462.783288] [c0000001c6c67860] [8000000000868f6c] >>> .bttv_qbuf+0x50/0x64 [bttv] >>> [ 462.783383] [c0000001c6c678e0] [80000000007bf208] >>> .v4l_qbuf+0x54/0x60 [videodev] >>> [ 462.783402] [c0000001c6c67970] [80000000007c1eac] >>> .__video_do_ioctl+0x30c/0x3f8 [videodev] >>> [ 462.783421] [c0000001c6c67a80] [80000000007c3c08] >>> .video_usercopy+0x18c/0x3dc [videodev] >>> [ 462.783440] [c0000001c6c67c00] [80000000007bb14c] >>> .v4l2_ioctl+0x60/0x78 [videodev] >>> [ 462.783460] [c0000001c6c67c90] [80000000007d3c48] >>> .v4l2_compat_ioctl32+0x9b4/0x1850 [videodev] >>> [ 462.783468] [c0000001c6c67d70] [c0000000001ad9cc] >>> .__se_compat_sys_ioctl+0x284/0x127c >>> [ 462.783473] [c0000001c6c67e20] [c00000000000067c] >>> system_call+0x60/0x6c >>> [ 462.783475] Instruction dump: >>> [ 462.783477] 40fe0044 60000000 892255d0 2f890000 40fe0020 3c82ffc5 >>> 39200001 60000000 >>> [ 462.783483] 38842029 992255d0 485ad0d9 60000000 <0fe00000> >>> 38210070 e8010010 7c0803a6 >>> [ 462.783490] ---[ end trace b677d4a00458e277 ]--- >>> >>> ----- >>> >>> dmesg fsl p5040: https://bugzilla.kernel.org/attachment.cgi?id=285813 >>> >>> Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500 >>> board (CPU: P5040 and P5020): >>> https://bugzilla.kernel.org/attachment.cgi?id=285815 >>> >>> Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=205201 >>> >>> Thanks for your help, >>> >>> Christian >> >> Christoph, >> >> Do you have another patch for testing or shall I bisect? >> >> Thanks, >> Christian > > Hi Christoph, > > I have seen that I have activated the kernel config option > CONFIG_ARCH_DMA_ADDR_T_64BIT. That means your code in your patch won't > work if this kernel option is enabled. > > +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT > + /* Check if DMA address overflowed */ > + if (min(addr, addr + size - 1) < > + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) > + return false; > +#endif > > I will delete the lines with ifndef and endif and will try it again. > > Cheers, > Christian Christoph, I have seen that the patch above isn't from you. It's from Nicolas Saenz Julienne. Cheers, Christian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug 205201 - overflow of DMA mask and bus mask 2019-11-11 8:16 ` Christian Zigotzky @ 2019-11-11 12:22 ` Christian Zigotzky 2019-11-12 14:41 ` Christoph Hellwig 0 siblings, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2019-11-11 12:22 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, darren, mad skateman, linux-kernel, linux-mm, iommu, Rob Herring, paulus, rtd2, contact, linuxppc-dev, nsaenzjulienne On 11 November 2019 at 09:16 am, Christian Zigotzky wrote: > On 11 November 2019 at 09:12 am, Christian Zigotzky wrote: >> On 10 November 2019 at 08:27 am, Christian Zigotzky wrote: >>> On 07 November 2019 at 10:53 am, Christian Zigotzky wrote: >>>> On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote: >>>>> On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote: >>>>>> Hi All, >>>>>> >>>>>> We still have DMA problems with some PCI devices. Since the >>>>>> PowerPC updates >>>>>> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if >>>>>> we want to >>>>>> work with our PCI devices. The FSL P5020 and P5040 have these >>>>>> problems >>>>>> currently. >>>>>> >>>>>> Error message: >>>>>> >>>>>> [ 25.654852] bttv 1000:04:05.0: overflow >>>>>> 0x00000000fe077000+4096 of DMA >>>>>> mask ffffffff bus mask df000000 >>>>>> >>>>>> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so >>>>>> booting >>>>>> of a Linux userland isn't possible. >>>>>> >>>>>> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. >>>>>> The kernel >>>>>> 4.20 works with all PCI devices without limitation of RAM. >>>>> Can you send me the .config and a dmesg? And in the meantime try the >>>>> patch below? >>>>> >>>>> --- >>>>> >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 >>>>> 2001 >>>>> From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >>>>> Date: Fri, 18 Oct 2019 13:00:43 +0200 >>>>> Subject: dma-direct: check for overflows on 32 bit DMA addresses >>>>> >>>>> As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation >>>>> it is >>>>> possible for a device configured with 32 bit DMA addresses and a >>>>> partial >>>>> DMA mapping located at the end of the address space to overflow. It >>>>> happens when a higher physical address, not DMAable, is translated to >>>>> it's DMA counterpart. >>>>> >>>>> For example the Raspberry Pi 4, configurable up to 4 GB of memory, >>>>> has >>>>> an interconnect capable of addressing the lower 1 GB of physical >>>>> memory >>>>> with a DMA offset of 0xc0000000. It transpires that, any attempt to >>>>> translate physical addresses higher than the first GB will result >>>>> in an >>>>> overflow which dma_capable() can't detect as it only checks for >>>>> addresses bigger then the maximum allowed DMA address. >>>>> >>>>> Fix this by verifying in dma_capable() if the DMA address range >>>>> provided >>>>> is at any point lower than the minimum possible DMA address on the >>>>> bus. >>>>> >>>>> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >>>>> --- >>>>> include/linux/dma-direct.h | 8 ++++++++ >>>>> 1 file changed, 8 insertions(+) >>>>> >>>>> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h >>>>> index adf993a3bd58..6ad9e9ea7564 100644 >>>>> --- a/include/linux/dma-direct.h >>>>> +++ b/include/linux/dma-direct.h >>>>> @@ -3,6 +3,7 @@ >>>>> #define _LINUX_DMA_DIRECT_H 1 >>>>> #include <linux/dma-mapping.h> >>>>> +#include <linux/memblock.h> /* for min_low_pfn */ >>>>> #include <linux/mem_encrypt.h> >>>>> #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA >>>>> @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device >>>>> *dev, dma_addr_t addr, size_t size) >>>>> if (!dev->dma_mask) >>>>> return false; >>>>> +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT >>>>> + /* Check if DMA address overflowed */ >>>>> + if (min(addr, addr + size - 1) < >>>>> + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << >>>>> PAGE_SHIFT))) >>>>> + return false; >>>>> +#endif >>>>> + >>>>> return addr + size - 1 <= >>>>> min_not_zero(*dev->dma_mask, dev->bus_dma_mask); >>>>> } >>>> Hello Christoph, >>>> >>>> Thanks a lot for your patch! Unfortunately this patch doesn't solve >>>> the issue. >>>> >>>> Error messages: >>>> >>>> [ 6.041163] bttv: driver version 0.9.19 loaded >>>> [ 6.041167] bttv: using 8 buffers with 2080k (520 pages) each >>>> for capture >>>> [ 6.041559] bttv: Bt8xx card found (0) >>>> [ 6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19, >>>> latency: 128, mmio: 0xc20001000 >>>> [ 6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1 >>>> TV Station RDS [card=53,insmod option] >>>> [ 6.042216] bttv: 0: tuner type=5 >>>> [ 6.111994] bttv: 0: audio absent, no audio device found! >>>> [ 6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up >>>> to 100ms) >>>> [ 6.200005] bttv: PLL set ok >>>> [ 6.209351] bttv: 0: registered device video0 >>>> [ 6.211576] bttv: 0: registered device vbi0 >>>> [ 6.214897] bttv: 0: registered device radio0 >>>> [ 114.218806] bttv 1000:04:05.0: overflow 0x00000000ff507000+4096 >>>> of DMA mask ffffffff bus mask df000000 >>>> [ 114.218848] Modules linked in: rfcomm bnep tuner_simple >>>> tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x >>>> tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc btusb >>>> btrtl btbcm btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc >>>> [ 114.219012] [c0000001ecddf720] [80000000008ff6e8] >>>> .buffer_prepare+0x150/0x268 [bttv] >>>> [ 114.219029] [c0000001ecddf860] [80000000008fff6c] >>>> .bttv_qbuf+0x50/0x64 [bttv] >>>> >>>> ----- >>>> >>>> Trace: >>>> >>>> [ 462.783184] Call Trace: >>>> [ 462.783187] [c0000001c6c67420] [c0000000000b3358] >>>> .report_addr+0xb8/0xc0 (unreliable) >>>> [ 462.783192] [c0000001c6c67490] [c0000000000b351c] >>>> .dma_direct_map_page+0xf0/0x128 >>>> [ 462.783195] [c0000001c6c67530] [c0000000000b35b0] >>>> .dma_direct_map_sg+0x5c/0xac >>>> [ 462.783205] [c0000001c6c675e0] [8000000000862e88] >>>> .__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg] >>>> [ 462.783220] [c0000001c6c676b0] [8000000000854274] >>>> .videobuf_iolock+0x98/0xb4 [videobuf_core] >>>> [ 462.783271] [c0000001c6c67720] [80000000008686e8] >>>> .buffer_prepare+0x150/0x268 [bttv] >>>> [ 462.783276] [c0000001c6c677c0] [8000000000854afc] >>>> .videobuf_qbuf+0x2b8/0x428 [videobuf_core] >>>> [ 462.783288] [c0000001c6c67860] [8000000000868f6c] >>>> .bttv_qbuf+0x50/0x64 [bttv] >>>> [ 462.783383] [c0000001c6c678e0] [80000000007bf208] >>>> .v4l_qbuf+0x54/0x60 [videodev] >>>> [ 462.783402] [c0000001c6c67970] [80000000007c1eac] >>>> .__video_do_ioctl+0x30c/0x3f8 [videodev] >>>> [ 462.783421] [c0000001c6c67a80] [80000000007c3c08] >>>> .video_usercopy+0x18c/0x3dc [videodev] >>>> [ 462.783440] [c0000001c6c67c00] [80000000007bb14c] >>>> .v4l2_ioctl+0x60/0x78 [videodev] >>>> [ 462.783460] [c0000001c6c67c90] [80000000007d3c48] >>>> .v4l2_compat_ioctl32+0x9b4/0x1850 [videodev] >>>> [ 462.783468] [c0000001c6c67d70] [c0000000001ad9cc] >>>> .__se_compat_sys_ioctl+0x284/0x127c >>>> [ 462.783473] [c0000001c6c67e20] [c00000000000067c] >>>> system_call+0x60/0x6c >>>> [ 462.783475] Instruction dump: >>>> [ 462.783477] 40fe0044 60000000 892255d0 2f890000 40fe0020 >>>> 3c82ffc5 39200001 60000000 >>>> [ 462.783483] 38842029 992255d0 485ad0d9 60000000 <0fe00000> >>>> 38210070 e8010010 7c0803a6 >>>> [ 462.783490] ---[ end trace b677d4a00458e277 ]--- >>>> >>>> ----- >>>> >>>> dmesg fsl p5040: https://bugzilla.kernel.org/attachment.cgi?id=285813 >>>> >>>> Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500 >>>> board (CPU: P5040 and P5020): >>>> https://bugzilla.kernel.org/attachment.cgi?id=285815 >>>> >>>> Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=205201 >>>> >>>> Thanks for your help, >>>> >>>> Christian >>> >>> Christoph, >>> >>> Do you have another patch for testing or shall I bisect? >>> >>> Thanks, >>> Christian >> >> Hi Christoph, >> >> I have seen that I have activated the kernel config option >> CONFIG_ARCH_DMA_ADDR_T_64BIT. That means your code in your patch >> won't work if this kernel option is enabled. >> >> +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT >> + /* Check if DMA address overflowed */ >> + if (min(addr, addr + size - 1) < >> + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) >> + return false; >> +#endif >> >> I will delete the lines with ifndef and endif and will try it again. >> >> Cheers, >> Christian > > Christoph, > > I have seen that the patch above isn't from you. It's from Nicolas > Saenz Julienne. > > Cheers, > Christian Christoph, Now, I can definitely say that this patch does not solve the issue. Do you have another patch for testing or shall I bisect? Thanks, Christian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug 205201 - overflow of DMA mask and bus mask 2019-11-11 12:22 ` Christian Zigotzky @ 2019-11-12 14:41 ` Christoph Hellwig 2019-11-12 22:58 ` Christian Zigotzky 2019-11-13 10:14 ` Christian Zigotzky 0 siblings, 2 replies; 21+ messages in thread From: Christoph Hellwig @ 2019-11-12 14:41 UTC (permalink / raw) To: Christian Zigotzky Cc: linux-arch, darren, mad skateman, linux-kernel, linux-mm, iommu, Rob Herring, paulus, rtd2, contact, linuxppc-dev, Christoph Hellwig, nsaenzjulienne On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote: > Now, I can definitely say that this patch does not solve the issue. > > Do you have another patch for testing or shall I bisect? I'm still interested in the .config and dmesg. Especially if the board is using arch/powerpc/sysdev/fsl_pci.c, which is the only place inside the powerpc arch code doing funny things with the bus_dma_mask, which Robin pointed out looks fishy. > > Thanks, > Christian ---end quoted text--- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug 205201 - overflow of DMA mask and bus mask 2019-11-12 14:41 ` Christoph Hellwig @ 2019-11-12 22:58 ` Christian Zigotzky 2019-11-13 10:14 ` Christian Zigotzky 1 sibling, 0 replies; 21+ messages in thread From: Christian Zigotzky @ 2019-11-12 22:58 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, darren, mad skateman, linux-kernel, linux-mm, iommu, Rob Herring, paulus, rtd2, contact, linuxppc-dev, nsaenzjulienne On 12 November 2019 at 3:41 pm, Christoph Hellwig wrote: > On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote: >> Now, I can definitely say that this patch does not solve the issue. >> >> Do you have another patch for testing or shall I bisect? > I'm still interested in the .config and dmesg. Especially if the > board is using arch/powerpc/sysdev/fsl_pci.c, which is the only > place inside the powerpc arch code doing funny things with the > bus_dma_mask, which Robin pointed out looks fishy. > Here you are: .config: https://bugzilla.kernel.org/attachment.cgi?id=285815 dmesg: https://bugzilla.kernel.org/attachment.cgi?id=285813 Thanks ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug 205201 - overflow of DMA mask and bus mask 2019-11-12 14:41 ` Christoph Hellwig 2019-11-12 22:58 ` Christian Zigotzky @ 2019-11-13 10:14 ` Christian Zigotzky 2019-11-13 11:02 ` Christoph Hellwig 1 sibling, 1 reply; 21+ messages in thread From: Christian Zigotzky @ 2019-11-13 10:14 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch, darren, mad skateman, linux-kernel, linux-mm, iommu, Rob Herring, paulus, rtd2, contact, linuxppc-dev, nsaenzjulienne Hello Christoph, I have found the issue. :-) GFP_DMA32 was renamed to GFP_DMA in the PowerPC updates 4.21-1 in December last year. Some PCI devices still use GFP_DMA32 (grep -r GFP_DMA32 *). I renamed GFP_DMA32 to GFP_DMA in the file "drivers/media/v4l2-core/videobuf-dma-sg.c". After compiling the RC7 of kernel 5.4 my TV card works again. Cheers, Christian On 12 November 2019 at 3:41 pm, Christoph Hellwig wrote: > On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote: >> Now, I can definitely say that this patch does not solve the issue. >> >> Do you have another patch for testing or shall I bisect? > I'm still interested in the .config and dmesg. Especially if the > board is using arch/powerpc/sysdev/fsl_pci.c, which is the only > place inside the powerpc arch code doing funny things with the > bus_dma_mask, which Robin pointed out looks fishy. > >> Thanks, >> Christian > ---end quoted text--- > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bug 205201 - overflow of DMA mask and bus mask 2019-11-13 10:14 ` Christian Zigotzky @ 2019-11-13 11:02 ` Christoph Hellwig 0 siblings, 0 replies; 21+ messages in thread From: Christoph Hellwig @ 2019-11-13 11:02 UTC (permalink / raw) To: Christian Zigotzky Cc: linux-arch, darren, mad skateman, linux-kernel, linux-mm, iommu, Rob Herring, paulus, rtd2, contact, linuxppc-dev, Christoph Hellwig, nsaenzjulienne Interesting. Give me some time to come up with a real fix, as drivers really should not mess with GFP flags for these allocations, and even if they did swiotlb is supposed to take care of any resulting problems. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2019-11-13 11:07 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <7b549219-a2e1-08c7-331b-9c3e4fdb8a8f@xenosoft.de> [not found] ` <3aeae0d8-e9be-2585-cbbd-70263cb495f1@xenosoft.de> [not found] ` <20191015125105.GU25745@shell.armlinux.org.uk> [not found] ` <5611f3bc-68aa-78ec-182a-1cb414202314@xenosoft.de> [not found] ` <20191015131750.GV25745@shell.armlinux.org.uk> 2019-10-23 5:42 ` Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates Michael Ellerman 2019-10-23 6:41 ` Benjamin Herrenschmidt 2019-10-23 13:52 ` Rob Herring 2019-10-23 14:12 ` Russell King - ARM Linux admin 2019-10-23 14:31 ` Russell King - ARM Linux admin 2019-10-25 22:28 ` Rob Herring 2019-10-26 6:39 ` Christoph Hellwig 2019-10-28 8:47 ` Benjamin Herrenschmidt 2019-10-28 8:45 ` Benjamin Herrenschmidt 2019-10-23 14:20 ` Christian Zigotzky 2019-11-04 14:44 ` Christian Zigotzky 2019-11-05 7:50 ` Bug 205201 - overflow of DMA mask and bus mask Christian Zigotzky 2018-12-13 11:25 use generic DMA mapping code in powerpc V4 Christoph Hellwig 2018-12-13 13:34 ` Christian Zigotzky 2018-12-13 17:48 ` Christian Zigotzky 2018-12-13 21:53 ` Christian Zigotzky 2018-12-14 12:00 ` Christian Zigotzky 2019-01-03 7:36 ` Christoph Hellwig 2019-01-03 19:26 ` Christian Zigotzky 2019-01-05 16:03 ` Christian Zigotzky 2019-01-09 9:31 ` Christian Zigotzky [not found] ` <46025f1b-db20-ac23-7dcd-10bc43bbb6ee@xenosoft.de> [not found] ` <20191105162856.GA15402@lst.de> 2019-11-07 9:53 ` Bug 205201 - overflow of DMA mask and bus mask Christian Zigotzky 2019-11-10 7:27 ` Christian Zigotzky 2019-11-11 8:12 ` Christian Zigotzky 2019-11-11 8:16 ` Christian Zigotzky 2019-11-11 12:22 ` Christian Zigotzky 2019-11-12 14:41 ` Christoph Hellwig 2019-11-12 22:58 ` Christian Zigotzky 2019-11-13 10:14 ` Christian Zigotzky 2019-11-13 11:02 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).