Re: [PATCH] docs: document python version used for compilation
On Fri May 31, 2024 at 9:33 AM CEST, Geert Uytterhoeven wrote:
> Hi Thierry,
>
> On Thu, May 30, 2024 at 7:07 PM Thierry Reding
> wrote:
> > Alternatively, maybe Kconfig could be taught about build dependencies?
>
> git grep "depends on \$(" -- "*Kconf*"
Duh... of course there's something like this already. =)
Maybe something like the attached patch?
Thierry
From 153eaec61513e14f5a7f8f2a998600d07f17bc84 Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Fri, 31 May 2024 10:51:42 +0200
Subject: [PATCH] kbuild: Allow Kconfig dependendencies on Python
Recently drivers have started depending on Python to generate register
definitions during the build process. In order to prevent such drivers
from breaking builds on systems that don't have Python installed, make
them depend on the minimum required Python version that they need via
Kconfig. If Python is not installed on the system, these drivers will
be automatically disabled.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/msm/Kconfig | 1 +
scripts/min-tool-version.sh | 3 +++
scripts/python-version.sh | 41 +
3 files changed, 45 insertions(+)
create mode 100755 scripts/python-version.sh
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 1931ecf73e32..5f7f84de55e4 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -11,6 +11,7 @@ config DRM_MSM
depends on QCOM_LLCC || QCOM_LLCC=n
depends on QCOM_COMMAND_DB || QCOM_COMMAND_DB=n
depends on PM
+ depends on $(success,$(srctree)/scripts/python-version.sh)
select IOMMU_IO_PGTABLE
select QCOM_MDT_LOADER if ARCH_QCOM
select REGULATOR
diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
index 91c91201212c..447a3ad4c0bf 100755
--- a/scripts/min-tool-version.sh
+++ b/scripts/min-tool-version.sh
@@ -38,6 +38,9 @@ rustc)
bindgen)
echo 0.65.1
;;
+python)
+ echo 3.5.0
+ ;;
*)
echo "$1: unknown tool" >&2
exit 1
diff --git a/scripts/python-version.sh b/scripts/python-version.sh
new file mode 100755
index ..c997d40418dc
--- /dev/null
+++ b/scripts/python-version.sh
@@ -0,0 +1,41 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Print the Python version in a 5 or 6-digit form.
+# Also, perform the minimum version check.
+
+set -e
+
+PYTHON=${PYTHON:-python}
+
+get_canonical_version()
+{
+ IFS=.
+ set -- $1
+
+ # If the 2nd or 3rd field is missing, fill it with a zero.
+ echo $((1 * $1 + 100 * ${2:-0} + ${3:-0}))
+}
+
+output=$(LC_ALL=C "$PYTHON" --version)
+
+# Split the line on spaces.
+IFS=' '
+set -- $output
+name=$1
+version=$2
+
+min_tool_version=$(dirname $0)/min-tool-version.sh
+min_version=$($min_tool_version python)
+
+cversion=$(get_canonical_version $version)
+min_version=$(get_canonical_version $min_version)
+
+if [ "$cversion" -lt "$min_version" ]; then
+ echo >&2 "***"
+ echo >&2 "*** Python is too old."
+ echo >&2 "***"
+ exit 1
+fi
+
+echo $name $version
--
2.44.0
signature.asc
Description: PGP signature
Re: [BUG] Build failure and alleged fix for next-20240523
On Thu May 30, 2024 at 6:55 PM CEST, Paul E. McKenney wrote:
> On Fri, May 24, 2024 at 12:57:58PM -0700, Abhinav Kumar wrote:
> > Hello
> >
> > On 5/24/2024 12:55 PM, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > I get the following allmodconfig build error on x86 in next-20240523:
> > >
> > > Traceback (most recent call last):
> > > File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in
> > >
> > > main()
> > > File "drivers/gpu/drm/msm/registers/gen_header.py", line 951, in main
> > > parser.add_argument('--validate',
> > > action=argparse.BooleanOptionalAction)
> > > AttributeError: module 'argparse' has no attribute 'BooleanOptionalAction'
> > >
> > > The following patch allows the build to complete successfully:
> > >
> > > https://patchwork.kernel.org/project/dri-devel/patch/20240508091751.336654-1-jonath...@nvidia.com/#25842751
> > >
> > > As to whether this is a proper fix, I must defer to the DRM folks on CC.
> >
> > Thanks for the report.
> >
> > I have raised a merge request for
> > https://patchwork.freedesktop.org/patch/593057/ to make it available for the
> > next fixes release for msm.
>
> Thank you!
>
> This still is not in -next, so I am putting it into -rcu just to silence
> the diagnostic. Or should I push this to mainline via -rcu?
I pushed this to drm-misc-fixes earlier today, so should show up in
linux-next soon and hopefully in v6.10-rc2.
Thierry
signature.asc
Description: PGP signature
Re: [PATCH] docs: document python version used for compilation
On Fri May 10, 2024 at 10:04 PM CEST, Rob Clark wrote: > On Fri, May 10, 2024 at 3:09 AM Jani Nikula wrote: > > > > On Fri, 10 May 2024, Mauro Carvalho Chehab wrote: > > > Em Fri, 10 May 2024 11:08:38 +0300 > > > Jani Nikula escreveu: > > > > > >> On Thu, 09 May 2024, Dmitry Baryshkov > > >> wrote: > > >> > The drm/msm driver had adopted using Python3 script to generate > > >> > register > > >> > header files instead of shipping pre-generated header files. Document > > >> > the minimal Python version supported by the script. > > >> > > > >> > Signed-off-by: Dmitry Baryshkov > > >> > --- > > >> > Documentation/process/changes.rst | 1 + > > >> > 1 file changed, 1 insertion(+) > > >> > > > >> > diff --git a/Documentation/process/changes.rst > > >> > b/Documentation/process/changes.rst > > >> > index 5685d7bfe4d0..8d225a9f65a2 100644 > > >> > --- a/Documentation/process/changes.rst > > >> > +++ b/Documentation/process/changes.rst > > >> > @@ -63,6 +63,7 @@ cpio any cpio > > >> > --version > > >> > GNU tar1.28 tar --version > > >> > gtags (optional) 6.6.5gtags --version > > >> > mkimage (optional) 2017.01 mkimage --version > > >> > +Python (optional) 3.5.xpython3 --version > > >> > > >> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in > > >> using anything older than the oldest supported version of Python, > > >> i.e. 3.8 at this time? > > > > > > What's the point of breaking compilation with on older distros? > > > The idea of minimal versions here is to specify the absolute minimum > > > version that it is required for the build to happen. If 3.5 is > > > the minimal one, then be it. > > > > AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should > > at least be aware *why* we'd be sticking to old versions. > > > > Minimum versions here also means sticking to features available in said > > versions, for Python just as well as for GCC or any other tool. That's > > not zero cost. > > At this point, the cost to having a lower minimum version is pretty > small, so I'm not worrying too much about it. > > Maybe once kernel developers discover mako, and start generating more > at build time, we'll have to re-evaluate. ;-) You're making an interesting point. Does the build dependency here denote Python (& standard library) or do we assume that if people have Python installed that they can also install arbitrary extra packages? Would a Mako dependency need to be explicitly mentioned here? Thierry signature.asc Description: PGP signature
Re: [PATCH] docs: document python version used for compilation
On Thu May 9, 2024 at 6:48 PM CEST, Jonathan Corbet wrote: > Dmitry Baryshkov writes: > > > The drm/msm driver had adopted using Python3 script to generate register > > header files instead of shipping pre-generated header files. Document > > the minimal Python version supported by the script. > > > > Signed-off-by: Dmitry Baryshkov > > --- > > Documentation/process/changes.rst | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/process/changes.rst > > b/Documentation/process/changes.rst > > index 5685d7bfe4d0..8d225a9f65a2 100644 > > --- a/Documentation/process/changes.rst > > +++ b/Documentation/process/changes.rst > > @@ -63,6 +63,7 @@ cpio any cpio --version > > GNU tar1.28 tar --version > > gtags (optional) 6.6.5gtags --version > > mkimage (optional) 2017.01 mkimage --version > > +Python (optional) 3.5.xpython3 --version > > == === > > > > Is it really optional - can you build the driver without it? > > This document needs some help... I'm missing a number of things that are > *not* marked as "optional" (jfsutils, reiserfsprogs, pcmciautils, ppp, > ...) and somehow my system works fine :) It would be nice to document > *why* users might need a specific tool. > > But I guess we aren't going to do that now. I can apply this, but I do > wonder about the "optional" marking. I guess it depends a bit on what exactly "optional" implies. It's optional in the sense that you can easily disable the driver and then build without Python. So does "optional" mean that allmodconfig for all platforms builds without the dependency? Or does it mean some definition of "core" kernel builds for a set of defined platforms? Maybe this really needs to be annotated with the exact Kconfig options that need this. Although that could get out of hands rather quickly. At some point we may have to list a *lot* of these options. Alternatively, maybe Kconfig could be taught about build dependencies? Thierry signature.asc Description: PGP signature
Re: [PATCH] drm/msm: remove python 3.9 dependency for compiling msm
On Wed May 8, 2024 at 1:04 AM CEST, Abhinav Kumar wrote:
> Since commit 5acf49119630 ("drm/msm: import gen_header.py script from Mesa"),
> compilation is broken on machines having python versions older than 3.9
> due to dependency on argparse.BooleanOptionalAction.
>
> Switch to use simple bool for the validate flag to remove the dependency.
>
> Fixes: 5acf49119630 ("drm/msm: import gen_header.py script from Mesa")
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/registers/gen_header.py | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Irrespective of whether we want to allow Python as a build dependency or
not, it already is since v6.10-rc1, so in the meantime I'm going to
apply this to drm-misc-fixes to unbreak things.
If we decide that we don't want the extra dependency we need revert the
whole generation infrastructure.
Thierry
signature.asc
Description: PGP signature
Re: [Freedreno] [PATCH] drm: Explicitly include correct DT includes
On Fri, Jul 14, 2023 at 11:45:34AM -0600, Rob Herring wrote: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring [Trimming the recipient list so that Google will let me send this] Test builds were fine, so I've pushed this to drm-misc now. Thierry signature.asc Description: PGP signature
Re: [Freedreno] [PATCH v5 09/13] drm/tegra: Use regular fbdev I/O helpers
On Tue, May 30, 2023 at 05:12:24PM +0200, Thomas Zimmermann wrote: > Use the regular fbdev helpers for framebuffer I/O instead of DRM's > helpers. Tegra does not use damage handling, so DRM's fbdev helpers > are mere wrappers around the fbdev code. > > By using fbdev helpers directly within each DRM fbdev emulation, > we can eventually remove DRM's wrapper functions entirely. > > v4: > * use initializer macros for struct fb_ops > v2: > * use FB_SYS_HELPERS option > > Signed-off-by: Thomas Zimmermann > Acked-by: Sam Ravnborg > Cc: Thierry Reding > Cc: Mikko Perttunen > Cc: Jonathan Hunter > --- > drivers/gpu/drm/tegra/Kconfig | 1 + > drivers/gpu/drm/tegra/fbdev.c | 8 +++----- > 2 files changed, 4 insertions(+), 5 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [Freedreno] [PATCH v2 05/20] drm/dp: Add backpointer to drm_device in drm_dp_aux
On Fri, Mar 26, 2021 at 04:37:52PM -0400, Lyude Paul wrote: > This is something that we've wanted for a while now: the ability to > actually look up the respective drm_device for a given drm_dp_aux struct. > This will also allow us to transition over to using the drm_dbg_*() helpers > for debug message printing, as we'll finally have a drm_device to reference > for doing so. > > Note that there is one limitation with this - because some DP AUX adapters > exist as platform devices which are initialized independently of their > respective DRM devices, one cannot rely on drm_dp_aux->drm_dev to always be > non-NULL until drm_dp_aux_register() has been called. We make sure to point > this out in the documentation for struct drm_dp_aux. > > Signed-off-by: Lyude Paul > --- [...] > drivers/gpu/drm/tegra/dpaux.c | 1 + [...] Acked-by: Thierry Reding signature.asc Description: PGP signature ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH v2 14/21] drm/tegra: Introduce GEM object functions
On Tue, Sep 15, 2020 at 04:59:51PM +0200, Thomas Zimmermann wrote: > GEM object functions deprecate several similar callback interfaces in > struct drm_driver. This patch replaces the per-driver callbacks with > per-instance callbacks in tegra. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/tegra/drm.c | 4 > drivers/gpu/drm/tegra/gem.c | 8 > 2 files changed, 8 insertions(+), 4 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH] of/device: add blacklist for iommu dma_ops
On Mon, Jun 03, 2019 at 07:20:14AM -0700, Rob Clark wrote: > On Mon, Jun 3, 2019 at 6:54 AM Thierry Reding > wrote: > > > > On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote: > > > On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote: > > > > > > > > On 03/06/2019 11:47, Rob Clark wrote: > > > > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa > > > > > wrote: > > > > >> > > > > >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > > > > >>> > > > > >>> So, another case I've come across, on the display side.. I'm working > > > > >>> on handling the case where bootloader enables display (and takes > > > > >>> iommu > > > > >>> out of reset).. as soon as DMA domain gets attached we get iommu > > > > >>> faults, because bootloader has already configured display for > > > > >>> scanout. > > > > >>> Unfortunately this all happens before actual driver is probed and > > > > >>> has > > > > >>> a chance to intervene. > > > > >>> > > > > >>> It's rather unfortunate that we tried to be clever rather than just > > > > >>> making drivers call some function to opt-in to the hookup of dma > > > > >>> iommu > > > > >>> ops :-( > > > > >> > > > > >> I think it still works for the 90% of cases and if 10% needs some > > > > >> explicit work in the drivers, that's better than requiring 100% of > > > > >> the > > > > >> drivers to do things manually. > > > > > > > > Right, it's not about "being clever", it's about not adding opt-in code > > > > to the hundreds and hundreds and hundreds of drivers which *might* ever > > > > find themselves used on a system where they would need the IOMMU's help > > > > for DMA. > > > > > > Well, I mean, at one point we didn't do the automatic iommu hookup, we > > > could have just stuck with that and added a helper so drivers could > > > request the hookup. Things wouldn't have been any more broken than > > > before, and when people bring up systems where iommu is required, they > > > could have added the necessary dma_iommu_configure() call. But that > > > is water under the bridge now. > > > > > > > >> Adding Marek who had the same problem on Exynos. > > > > > > > > > > I do wonder how many drivers need to iommu_map in their ->probe()? > > > > > I'm thinking moving the auto-hookup to after a successful probe(), > > > > > with some function a driver could call if they need mapping in probe, > > > > > might be a way to eventually get rid of the blacklist. But I've no > > > > > idea how to find the subset of drivers that would be broken without a > > > > > dma_setup_iommu_stuff() call in their probe. > > > > > > > > Wouldn't help much. That particular issue is nothing to do with DMA ops > > > > really, it's about IOMMU initialisation. On something like SMMUv3 there > > > > is literally no way to turn the thing on without blocking unknown > > > > traffic - it *has* to have stream table entries programmed before it can > > > > even allow stuff to bypass. > > > > > > fwiw, on these sdm850 laptops (and I think sdm845 boards like mtp and > > > db845c) the SMMU (v2) is taken out of bypass by the bootloader. Bjorn > > > has some patches for arm-smmu to read-back the state at boot. > > > > > > (Although older devices were booting with display enabled but SMMU in > > > bypass.) > > > > > > > The answer is either to either pay attention to the "Quiesce all DMA > > > > capable devices" part of the boot protocol (which has been there since > > > > pretty much forever), or to come up with some robust way of > > > > communicating "live" boot-time mappings to IOMMU drivers so that they > > > > can program themselves appropriately during probe. > > > > > > Unfortunately display lit up by bootloader is basically ubiquitous. > > > Every single android phone does it. All of the windows-arm laptops do > > > it. Basically 99.9% of things that have a display do it. It's a > > > tough prob
Re: [Freedreno] [PATCH] of/device: add blacklist for iommu dma_ops
On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote: > On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote: > > > > On 03/06/2019 11:47, Rob Clark wrote: > > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote: > > >> > > >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > > >>> > > >>> So, another case I've come across, on the display side.. I'm working > > >>> on handling the case where bootloader enables display (and takes iommu > > >>> out of reset).. as soon as DMA domain gets attached we get iommu > > >>> faults, because bootloader has already configured display for scanout. > > >>> Unfortunately this all happens before actual driver is probed and has > > >>> a chance to intervene. > > >>> > > >>> It's rather unfortunate that we tried to be clever rather than just > > >>> making drivers call some function to opt-in to the hookup of dma iommu > > >>> ops :-( > > >> > > >> I think it still works for the 90% of cases and if 10% needs some > > >> explicit work in the drivers, that's better than requiring 100% of the > > >> drivers to do things manually. > > > > Right, it's not about "being clever", it's about not adding opt-in code > > to the hundreds and hundreds and hundreds of drivers which *might* ever > > find themselves used on a system where they would need the IOMMU's help > > for DMA. > > Well, I mean, at one point we didn't do the automatic iommu hookup, we > could have just stuck with that and added a helper so drivers could > request the hookup. Things wouldn't have been any more broken than > before, and when people bring up systems where iommu is required, they > could have added the necessary dma_iommu_configure() call. But that > is water under the bridge now. > > > >> Adding Marek who had the same problem on Exynos. > > > > > > I do wonder how many drivers need to iommu_map in their ->probe()? > > > I'm thinking moving the auto-hookup to after a successful probe(), > > > with some function a driver could call if they need mapping in probe, > > > might be a way to eventually get rid of the blacklist. But I've no > > > idea how to find the subset of drivers that would be broken without a > > > dma_setup_iommu_stuff() call in their probe. > > > > Wouldn't help much. That particular issue is nothing to do with DMA ops > > really, it's about IOMMU initialisation. On something like SMMUv3 there > > is literally no way to turn the thing on without blocking unknown > > traffic - it *has* to have stream table entries programmed before it can > > even allow stuff to bypass. > > fwiw, on these sdm850 laptops (and I think sdm845 boards like mtp and > db845c) the SMMU (v2) is taken out of bypass by the bootloader. Bjorn > has some patches for arm-smmu to read-back the state at boot. > > (Although older devices were booting with display enabled but SMMU in bypass.) > > > The answer is either to either pay attention to the "Quiesce all DMA > > capable devices" part of the boot protocol (which has been there since > > pretty much forever), or to come up with some robust way of > > communicating "live" boot-time mappings to IOMMU drivers so that they > > can program themselves appropriately during probe. > > Unfortunately display lit up by bootloader is basically ubiquitous. > Every single android phone does it. All of the windows-arm laptops do > it. Basically 99.9% of things that have a display do it. It's a > tough problem to solve involving clks, gdsc, regulators, etc, in > addition to the display driver.. and sadly now smmu. And devices > where we can make changes to and update the firmware are rather rare. > So there is really no option to ignore this problem. I think this is going to require at least some degree of cooperation from the bootloader. See my other thread on that. Unfortunately I think this is an area where everyone has kind of been doing their own thing even if standard bindings for this have been around for quite a while (actually 5 years by now). I suspect that most bootloaders that run today are not that old, but as always downstream doesn't follow closely where upstream is guiding. > I guess if we had some early-quirks mechanism like x86 does, we could > mash the display off early in boot. That would be an easy solution. > Although I'd prefer a proper solution so that android phones aren't > carrying around enormous stacks of hack patches to achieve a smooth > flicker-free boot. The proper solution, I think, is for bootloader and kernel to work together. Unfortunately that means we'll just have to bite the bullet and get things fixed across the stack. I think this is just the latest manifestation of the catch-up that upstream has been playing. Only now that we're starting to enable all of these features upstream are we running into interoperability issues. If upstream had been further along we would've caught these issues way ahead of time and could've influenced the designs of bootloader much earlier. Now, unless we get all the vendors to go back and mo
Re: [Freedreno] [PATCH] of/device: add blacklist for iommu dma_ops
ommu > > > > faults, because bootloader has already configured display for scanout. > > > > Unfortunately this all happens before actual driver is probed and has > > > > a chance to intervene. > > > > > > > > It's rather unfortunate that we tried to be clever rather than just > > > > making drivers call some function to opt-in to the hookup of dma iommu > > > > ops :-( > > > > > > I think it still works for the 90% of cases and if 10% needs some > > > explicit work in the drivers, that's better than requiring 100% of the > > > drivers to do things manually. > > Right, it's not about "being clever", it's about not adding opt-in code to > the hundreds and hundreds and hundreds of drivers which *might* ever find > themselves used on a system where they would need the IOMMU's help for DMA. > > > > Adding Marek who had the same problem on Exynos. > > > > I do wonder how many drivers need to iommu_map in their ->probe()? > > I'm thinking moving the auto-hookup to after a successful probe(), > > with some function a driver could call if they need mapping in probe, > > might be a way to eventually get rid of the blacklist. But I've no > > idea how to find the subset of drivers that would be broken without a > > dma_setup_iommu_stuff() call in their probe. > > Wouldn't help much. That particular issue is nothing to do with DMA ops > really, it's about IOMMU initialisation. On something like SMMUv3 there is > literally no way to turn the thing on without blocking unknown traffic - it > *has* to have stream table entries programmed before it can even allow stuff > to bypass. > > The answer is either to either pay attention to the "Quiesce all DMA capable > devices" part of the boot protocol (which has been there since pretty much > forever), or to come up with some robust way of communicating "live" > boot-time mappings to IOMMU drivers so that they can program themselves > appropriately during probe. I ran into a similar issue not too long ago and I've been working on what I think is a correct fix for this problem. Unfortunately I went down the rabbit hole of trying to get all of the pieces in the bootloader merged before posting the kernel patches, and that's been taking a long time. Let me chime in here in the hope that it will be helpful to others. The problem that I ran into was pretty much the same thing that Rob encountered. We have some platforms that will initialize display over HDMI in an early bootloader to show a splash screen. During boot we would usually take over display hardware by just resetting it and then programming it from scratch. Ultimately we want to do seamless handover so that the kernel can take over the splash and replace it by the console when that's ready. But I'm getting ahead of myself. One of the things I've been trying to do is replace direct IOMMU API usage in the Tegra DRM driver by using DMA API only, which we need in order to fix some corner cases we ran into (I've now forgotten most of the details and I realize that my commit messages aren't all that helpful...). Anyway, when I started using the DMA API I was running into a massive amount of IOMMU faults starting at early boot. It took me a while to realize that this was because now the IOMMU was enabled before the driver had a chance to set up the IOMMU domain. I think the only way that we were getting around that was because we used to have a custom IOMMU driver on older Tegra device and don't expose DMA API compatible IOMMU domains. With newer Tegras using the ARM SMMU we don't really have that option anymore. So the root cause of this is that the bootloader initialized the display controller to scan out from a physical address (the bootloader does not set up the SMMU) and when the kernel attaches the display controller to the SMMU during early boot, the display controller ends up trying to fetch those physical addresses through the SMMU where no mapping for those addresses exists, hence causing these faults. The solution that I came up with is to use the reserved-memory bindings along with memory-region references in the display controller nodes. I have a patch for the Tegra SMMU driver that implements support for parsing this data (the IOMMU framework has infrastructure to do this, so I take it that this has come up before) and setting up 1:1 mappings right before the SMMU is enabled for a device. This works rather well in my testing. I've been using hard-coded values because the bootloader does not properly put the reserved memory regions into the DT. I've been trying to add that as a side-project, but it turned into a bit of a can of worms. These are all
Re: [Freedreno] [PATCH 7/7] drm: Split out drm_probe_helper.h
/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +- > drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 2 +- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +- > drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +- > drivers/gpu/drm/rockchip/rockchip_rgb.c | 2 +- > drivers/gpu/drm/sti/sti_crtc.c| 2 +- > drivers/gpu/drm/sti/sti_drv.c | 2 +- > drivers/gpu/drm/sti/sti_dvo.c | 2 +- > drivers/gpu/drm/sti/sti_hda.c | 2 +- > drivers/gpu/drm/sti/sti_hdmi.c| 2 +- > drivers/gpu/drm/sti/sti_tvout.c | 2 +- > drivers/gpu/drm/stm/drv.c | 2 +- > drivers/gpu/drm/stm/ltdc.c| 2 +- > drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +- > drivers/gpu/drm/sun4i/sun4i_crtc.c| 2 +- > drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +- > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 2 +- > drivers/gpu/drm/sun4i/sun4i_lvds.c| 2 +- > drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 +- > drivers/gpu/drm/sun4i/sun4i_tcon.c| 2 +- > drivers/gpu/drm/sun4i/sun4i_tv.c | 2 +- > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 2 +- > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 +- > drivers/gpu/drm/sun4i/sun8i_mixer.c | 2 +- > drivers/gpu/drm/sun4i/sun8i_ui_layer.c| 2 +- > drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 2 +- > drivers/gpu/drm/tegra/drm.h | 2 +- > drivers/gpu/drm/tegra/hdmi.c | 2 +- > drivers/gpu/drm/tegra/hub.c | 2 +- > drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 2 +- > drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +- > drivers/gpu/drm/tve200/tve200_drv.c | 2 +- > drivers/gpu/drm/udl/udl_connector.c | 1 + > drivers/gpu/drm/udl/udl_drv.c | 1 + > drivers/gpu/drm/udl/udl_main.c| 1 + > drivers/gpu/drm/vc4/vc4_crtc.c| 2 +- > drivers/gpu/drm/vc4/vc4_dpi.c | 2 +- > drivers/gpu/drm/vc4/vc4_dsi.c | 2 +- > drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- > drivers/gpu/drm/vc4/vc4_kms.c | 2 +- > drivers/gpu/drm/vc4/vc4_txp.c | 2 +- > drivers/gpu/drm/vc4/vc4_vec.c | 2 +- > drivers/gpu/drm/virtio/virtgpu_display.c | 2 +- > drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +- > drivers/gpu/drm/vkms/vkms_crtc.c | 2 +- > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > drivers/gpu/drm/vkms/vkms_output.c| 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 +- > drivers/gpu/drm/xen/xen_drm_front.c | 2 +- > drivers/gpu/drm/xen/xen_drm_front_conn.c | 2 +- > drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +- > drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +- > drivers/gpu/drm/zte/zx_drm_drv.c | 2 +- > drivers/gpu/drm/zte/zx_hdmi.c | 2 +- > drivers/gpu/drm/zte/zx_tvenc.c| 2 +- > drivers/gpu/drm/zte/zx_vga.c | 2 +- > drivers/gpu/drm/zte/zx_vou.c | 2 +- > drivers/staging/vboxvideo/vbox_irq.c | 2 +- > drivers/staging/vboxvideo/vbox_mode.c | 2 +- > include/drm/drm_crtc_helper.h | 16 -- > include/drm/drm_probe_helper.h| 50 +++ > 208 files changed, 256 insertions(+), 200 deletions(-) > create mode 100644 include/drm/drm_probe_helper.h Looks good to me: Acked-by: Thierry Reding signature.asc Description: PGP signature ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Tue, Nov 20, 2018 at 06:13:42PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Make life easier for drivers by simply passing the connector > to drm_hdmi_avi_infoframe_from_display_mode() and > drm_hdmi_avi_infoframe_quant_range(). That way drivers don't > need to worry about is_hdmi2_sink mess. > > Cc: Alex Deucher > Cc: "Christian König" > Cc: "David (ChunMing) Zhou" > Cc: Archit Taneja > Cc: Andrzej Hajda > Cc: Laurent Pinchart > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: Russell King > Cc: CK Hu > Cc: Philipp Zabel > Cc: Rob Clark > Cc: Ben Skeggs > Cc: Tomi Valkeinen > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: Thierry Reding > Cc: Eric Anholt > Cc: Shawn Guo > Cc: Ilia Mirkin > Cc: amd-...@lists.freedesktop.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedreno@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-te...@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 ++-- > drivers/gpu/drm/bridge/sii902x.c | 3 ++- > drivers/gpu/drm/bridge/sil-sii8620.c | 3 +-- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++- > drivers/gpu/drm/drm_edid.c| 33 ++- > drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++- > drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++- > drivers/gpu/drm/i915/intel_hdmi.c | 14 +- > drivers/gpu/drm/i915/intel_lspcon.c | 15 ++- > drivers/gpu/drm/i915/intel_sdvo.c | 10 --- > drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 ++- > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 3 ++- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 +++-- > drivers/gpu/drm/omapdrm/omap_encoder.c| 5 ++-- > drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++- > drivers/gpu/drm/sti/sti_hdmi.c| 3 ++- > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 3 ++- > drivers/gpu/drm/tegra/hdmi.c | 3 ++- > drivers/gpu/drm/tegra/sor.c | 3 ++- > drivers/gpu/drm/vc4/vc4_hdmi.c | 11 +--- > drivers/gpu/drm/zte/zx_hdmi.c | 4 ++- > include/drm/drm_edid.h| 8 +++--- > 27 files changed, 94 insertions(+), 66 deletions(-) That's actually a lot nicer: Acked-by: Thierry Reding signature.asc Description: PGP signature ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
On Mon, Nov 12, 2018 at 04:01:14PM +0100, Maarten Lankhorst wrote: > We already have __drm_atomic_helper_connector_reset() and > __drm_atomic_helper_plane_reset(), extend this to crtc as well. > > Most drivers already have a gpu reset hook, correct it. > Nouveau already implemented its own __drm_atomic_helper_crtc_reset(), > convert it to the common one. > > Signed-off-by: Maarten Lankhorst > Cc: Harry Wentland > Cc: Leo Li > Cc: Alex Deucher > Cc: "Christian König" > Cc: "David (ChunMing) Zhou" > Cc: David Airlie > Cc: Liviu Dudau > Cc: Brian Starkey > Cc: Mali DP Maintainers > Cc: Boris Brezillon > Cc: Nicolas Ferre > Cc: Alexandre Belloni > Cc: Ludovic Desroches > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: Philipp Zabel > Cc: CK Hu > Cc: Matthias Brugger > Cc: Rob Clark > Cc: Ben Skeggs > Cc: Tomi Valkeinen > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Eric Anholt > Cc: VMware Graphics > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Cc: Tony Cheng > Cc: Shirish S > Cc: Mikita Lipski > Cc: Bhawanpreet Lakha > Cc: David Francis > Cc: Anthony Koo > Cc: Jeykumar Sankaran > Cc: Jordan Crouse > Cc: Bruce Wang > Cc: Sravanthi Kollukuduru > Cc: Archit Taneja > Cc: Steve Kowalik > Cc: Carsten Behling > Cc: Haneen Mohammed > Cc: Daniel Vetter > Cc: Rodrigo Siqueira > Cc: Mahesh Kumar > Cc: amd-...@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: intel-...@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedreno@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-te...@vger.kernel.org > --- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +-- > drivers/gpu/drm/arm/malidp_crtc.c | 5 +-- > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 5 +-- > drivers/gpu/drm/drm_atomic_state_helper.c | 31 --- > drivers/gpu/drm/i915/intel_display.c | 2 +- > drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +-- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +-- > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++- > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +--- > drivers/gpu/drm/nouveau/dispnv50/head.c | 13 ++-- > drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ++--- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +-- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +++-- > drivers/gpu/drm/tegra/dc.c| 5 +-- > drivers/gpu/drm/vc4/vc4_crtc.c | 8 ++--- > drivers/gpu/drm/vkms/vkms_crtc.c | 7 + > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +- > include/drm/drm_atomic_state_helper.h | 2 ++ > 18 files changed, 56 insertions(+), 81 deletions(-) Looks good to me: Acked-by: Thierry Reding signature.asc Description: PGP signature ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH] drm/core: Remove drm_dev_unref() and it's uses
On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref() with drm_dev_put and remove
> the function itself.
>
> Coccinelle was used for mass-patching.
>
> Signed-off-by: Vaishali Thakkar
Yes, please.
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH 00/15] drm: More plane clipping polish
On Thu, Nov 23, 2017 at 09:04:47PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > This series first unifies all users of drm_atomic_helper_check_plane_state() > to populate the clip rectangle with drm_mode_get_hv_timing(), and once > everything is unified the clip rectangle handling is sucked into > drm_atomic_helper_check_plane_state() away from driver code. > > Entire series available here: > git://github.com/vsyrjala/linux.git atomic_plane_helper_clip > > Cc: Archit Taneja > Cc: Ben Skeggs > Cc: Brian Starkey > Cc: CK Hu > Cc: Daniel Vetter > Cc: freedreno@lists.freedesktop.org > Cc: Laurent Pinchart > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: linux-te...@vger.kernel.org > Cc: Liviu Dudau > Cc: Mali DP Maintainers > Cc: Mark Yao > Cc: Neil Armstrong > Cc: Noralf Trønnes > Cc: nouv...@lists.freedesktop.org > Cc: Philipp Zabel > Cc: Rob Clark > Cc: Shawn Guo > Cc: Sinclair Yeh > Cc: Thierry Reding > Cc: Thomas Hellstrom > Cc: VMware Graphics > > Ville Syrjälä (15): > drm/i915: Reject odd pipe source width with double wide/dual link > drm/i915: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane > clip rectangle > drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle > drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/meson: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/nouveau/kms/nv50: Use drm_mode_get_hv_timing() to populate plane > clip rectangle > drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle > drm: Don't pass clip to drm_atomic_helper_check_plane_state() > > drivers/gpu/drm/arm/hdlcd_crtc.c| 6 +- > drivers/gpu/drm/arm/malidp_planes.c | 5 + > drivers/gpu/drm/armada/armada_overlay.c | 2 +- > drivers/gpu/drm/drm_atomic_helper.c | 12 +++- > drivers/gpu/drm/drm_plane_helper.c | 11 +++ > drivers/gpu/drm/drm_simple_kms_helper.c | 5 - > drivers/gpu/drm/i915/intel_atomic_plane.c | 8 > drivers/gpu/drm/i915/intel_display.c| 12 +++- > drivers/gpu/drm/i915/intel_drv.h| 1 - > drivers/gpu/drm/i915/intel_sprite.c | 8 ++-- > drivers/gpu/drm/imx/ipuv3-plane.c | 7 +-- > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 6 +- > drivers/gpu/drm/meson/meson_plane.c | 6 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++ > drivers/gpu/drm/nouveau/nv50_display.c | 8 > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 +--- > drivers/gpu/drm/tegra/dc.c | 8 +--- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +--- > drivers/gpu/drm/zte/zx_plane.c | 15 +-- > include/drm/drm_atomic_helper.h | 1 - > include/drm/drm_plane_helper.h | 1 - > 21 files changed, 35 insertions(+), 117 deletions(-) The series: Reviewed-by: Thierry Reding signature.asc Description: PGP signature ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
