summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/i915_gem_stolen.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915/kbl: Introduce Kabylake platform defition.Rodrigo Vivi2015-10-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kabylake is a Intel® Processor containing Intel® HD Graphics following Skylake. It is Gen9p5, so it inherits everything from Skylake. Let's start by adding the platform separated from Skylake but reusing most of all features, functions etc. Later we rebase the PCI-ID patch without is_skylake=1 so we don't replace what original Author did there. Few IS_SKYLAKEs if statements are not being covered by this patch on purpose: - Workarounds: Kabylake is derivated from Skylake H0 so no W/As apply here. - GuC: A following patch removes Kabylake support with an explanation: No firmware available yet. - DMC/CSR: Done in a separated patch since we need to be carefull and load the version for revision 7 since Kabylake is Skylake H0. v2: relative cleaner commit message and added the missed IS_KABYLAKE to intel_i2c.c as pointed out by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Determine the stolen memory base address on gen2Ville Syrjälä2015-10-091-11/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There isn't an explicit stolen memory base register on gen2. Some old comment in the i915 code suggests we should get it via max_low_pfn_mapped, but that's clearly a bad idea on my MGM. The e820 map in said machine looks like this: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable [ 0.000000] BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data [ 0.000000] BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved That makes max_low_pfn_mapped = 1f6f0000, so assuming our stolen memory would start there would place it on top of some ACPI memory regions. So not a good idea as already stated. The 9MB region after the ACPI regions at 0x1f700000 however looks promising given that the macine reports the stolen memory size to be 8MB. Looking at the PGTBL_CTL register, the GTT entries are at offset 0x1fee00000, and given that the GTT entries occupy 128KB, it looks like the stolen memory could start at 0x1f700000 and the GTT entries would occupy the last 128KB of the stolen memory. After some more digging through chipset documentation, I've determined the BIOS first allocates space for something called TSEG (something to do with SMM) from the top of memory, and then it allocates the graphics stolen memory below that. Accordind to the chipset documentation TSEG has a fixed size of 1MB on 855. So that explains the top 1MB in the e820 region. And it also confirms that the GTT entries are in fact at the end of the the stolen memory region. Derive the stolen memory base address on gen2 the same as the BIOS does (TOM-TSEG_SIZE-stolen_size). There are a few differences between the registers on various gen2 chipsets, so a few different codepaths are required. 865G is again bit more special since it seems to support enough memory to hit 4GB address space issues. This means the PCI allocations will also affect the location of the stolen memory. Fortunately there appears to be the TOUD register which may give us the correct answer directly. But the chipset docs are a bit unclear, so I'm not 100% sure that the graphics stolen memory is always the last thing the BIOS steals. Someone would need to verify it on a real system. I tested this on the my 830 and 855 machines, and so far everything looks peachy. v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods v3: Fix TSEG size for 830 v4: Add missing 'else' (Chris) Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't use the first stolen page on BroadwellPaulo Zanoni2015-09-301-1/+16
| | | | | | | | | | | | | The spec says we just can't use it. v2: - Add WA name (Ville). - Add a big comment explaining that we still didn't fix the problem where we inherit a framebuffer on the first page (Chris, Ville). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Defer adding preallocated stolen objects to the VM listChris Wilson2015-09-241-10/+6Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When preallocating a stolen object during early initialisation, we may be running before we have setup the the global GTT VM state, in particular before we have initialised the range manager and associated lists. As this is the case, we defer binding the stolen object until we call i915_gem_setup_global_gtt(). Not only should we defer the binding, but we should also defer the VM list manipulation. Fixes regression uncovered by commit a2cad9dff4dd44d0244b966d980de9d602d87593 Author: Michał Winiarski <michal.winiarski@intel.com> Date: Wed Sep 16 11:49:00 2015 +0200 drm/i915/gtt: Do not initialize drm_mm twice. Whilst I am here remove the duplicate work leaving dangling pointers from the error path... v2: Typos galore before coffee. Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92099 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Tested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Implement stolen reserved detection for ctg/elkVille Syrjälä2015-09-231-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | Finally managed to dig up enough hints as to where the stolen reserved stuff lives on ctg/elk. So add the code to decode it. This was a combination of old chipset specs, diggin up an old elk grits release with an ctg/elk AubLoad etc. This was only tested on an elk as I don't have a ctg here unfortunately. This leaves ilk as the only platform that doesn't have a way to detect this stuff. Looking at the register contents on my ilk, it might be that the elk way works there too, but I can't be sure since I can't affect the amount of reserved memory on that machine, and if I am to trust the register contents, by default it would reserve 0 bytes. v2: s/WARN_ON_ONCE/WARN_ON/ since it's in one time init code anyway (Paulo) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: avoid the last 8mb of stolen on BDW/SKLPaulo Zanoni2015-09-231-7/+19
| | | | | | | | | | | | | | | The FBC hardware for these platforms doesn't have access to the bios_reserved range, so it always assumes the maximum (8mb) is used. So avoid this range while allocating. This solves a bunch of FIFO underruns that happen if you end up putting the CFB in that memory range. On my machine, with 32mb of stolen, I need a 2560x1440 mode for that. Testcase: igt/kms_frontbuffer_tracking/fbc-* (given the right setup) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Set stolen reserved to 0 for pre-g4x platformsVille Syrjälä2015-09-141-1/+4
| | | | | | | | | | | | | | | | | | | | This stolen reserved stuff was introduced on g4x, so no need to waste stolen on older platforms. Unfortunately configdb is no more so I can't look up the right way to detect this stuff. I do have one hint as to where the register might be on ctg, but I don't have a ctg to test it, and on the elk I have here it doesn't contain sensible looking data. For ilk grits suggegsts it might be in the same place as on snb (the original PCI reg, not the mirror) but I can't be entirely sure about it The register shows a round zero on my ilk. So when there's no really good data for any of these platforms leave the current "assume 1MiB" approach in place. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix build warning on 32-bitThierry Reding2015-08-261-1/+1
| | | | | | | | | The gtt.stolen_size field is of type size_t, and so should be printed using %zu to avoid build warnings on either 32-bit and 64-bit builds. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: fix stolen bios_reserved checksPaulo Zanoni2015-08-141-16/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I started digging this when I noticed that the BDW code was just reserving 1mb by coincidence since it was reading reserved fields. Then I noticed we didn't have any values set for SNB and earlier, and that the HSW sizes were wrong. After that, I noticed that the reserved area has a specific start, and may not exactly end where the stolen memory ends. I also noticed the base pointer can be zero. So I decided to just write a single patch fixing everything instead of 20 patches that would be much harder to review. This patch may solve random stolen memory corruption/problems on almost all platforms. Notice that since this is always dealing with the top of the stolen memory, the problems are not so easy to reproduce - especially since FBC is still disabled by default. One of the major differences of this patch is that we now look at both the size and base address. By only looking at the size we were assuming that the reserved area was always at the very top of stolen, which is not always true. After we merge the patch series that allows user space to allocate stolen memory we'll be able to write IGT tests that maybe catch the bugs fixed by this patch. v2: - s/BIOS reserved/stolen reserved/g (Chris) - Don't DRM_ERROR if we can't do anything about it (Chris) - Improve debug messages (Chris). - Use the gen7 version instead of gen6 on HSW. Tom found some documentation problems, so I think with gen7 we're on the safer side (Tom). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'drm-intel-fixes-2015-07-15' into drm-intel-next-queuedDaniel Vetter2015-07-151-1/+0Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge fixes since it's getting out of hand again with the massive split due to atomic between -next and 4.2-rc. All the bugfixes in 4.2-rc are addressed already (by converting more towards atomic instead of minimal duct-tape) so just always pick the version in next for the conflicts in modeset code. All the other conflicts are just adjacent lines changed. Conflicts: drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_gem_gtt.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h drivers/gpu/drm/i915/intel_ringbuffer.h Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm/i915: remove unused has_dma_mapping flagImre Deak2015-07-131-1/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | After the previous patch this flag will check always clear, as it's never set for shmem backed and userptr objects, so we can remove it. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Yeah this isn't really fixes but it's a nice cleanup to clarify the code but not really worth the hassle of backmerging. So just add to -fixes, we're still early in -rc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add dev_priv->mm.stolen_lockPaulo Zanoni2015-07-061-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Which should protect dev_priv->mm.stolen usage. This will allow us to simplify the relationship between stolen memory, FBC and struct_mutex. v2: - Rebase after the stolen_remove_node() dev_priv patch move. - I realized that after we fixed a few things related to the FBC CFB size checks, we're not reallocating the CFB anymore with FBC enabled, so we can just move all the locking to i915_gem_stolen.c and stop worrying about freezing all the stolen alocations while freeing/rellocating the CFB. This allows us to fix the "Too coarse" observation from Chris. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: move FBC code out of i915_gem_stolen.cPaulo Zanoni2015-07-061-127/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the abstractions created by the last patch, we can move this code and the only thing inside intel_fbc.c that knows about dev_priv->mm is the code that reads stolen_base. We also had to move a call to i915_gem_stolen_cleanup_compression() - now called intel_fbc_cleanup_cfb() - outside i915_gem_stolen.c. v2: - Rebase after the remove_node() changes on the previous patch. Requested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add simple wrappers for stolen node insertion/removalPaulo Zanoni2015-07-061-16/+32
|/ | | | | | | | | | | | | | | | | We want to move the FBC code out of i915_gem_stolen.c, but that code directly adds/removes stolen memory nodes. Let's create this abstraction, so i915_gme_stolen.c is still in control of all the stolen memory handling. The abstraction will also allow us to add locking assertions later. v2: - Add dev_priv as remove_node() argument since we'll need it later (Chris). Requested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use proper FBC base register on all new platformsImre Deak2015-04-091-1/+1
| | | | | | | | | | | | Starting from GEN5 the FBC base register is the same on all platforms. GEN>=5 is the same condition as HAS_PCH_SPLIT except on BXT, so make things work on BXT as well. Motivated by Rodrigo's request to check FBC support on BXT. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v4.0-rc3' into drm-nextDave Airlie2015-03-091-4/+2Star
|\ | | | | | | | | | | | | | | | | Linux 4.0-rc3 backmerge to fix two i915 conflicts, and get some mainline bug fixes needed for my testing box Conflicts: drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/intel_display.c
| * drm/i915: Align initial plane backing objects correctlyDaniel Vetter2015-02-241-4/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some bios really like to joke and start the planes at an offset ... hooray! Align start and end to fix this. v2: Fixup calculation of size, spotted by Chris Wilson. v3: Fix serious fumble I've just spotted. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883 Cc: stable@vger.kernel.org Cc: Johannes W <jargon@molb.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by: Johannes W <jargon@molb.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> [Jani: split WARN_ONs, rebase on v4.0-rc1] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: don't reallocate the compressed FB at every framePaulo Zanoni2015-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | With the current code we just reallocate the compressed FB at every FBC update: we have X in one frame, then in the other frame we need X again, but we check "needed < have" instead of "needed <= have". v2: Rebase after Jani addressed the other problems described in v1. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915/fbc: fix the check for already reserved fbc sizeJani Nikula2015-02-131-4/+4
|/ | | | | | | | | | | | | | | | | | | | | | The check for previously reserved stolen space size for FBC in i915_gem_stolen_setup_compression() did not take the compression threshold into account. Fix this by storing and comparing to uncompressed size instead. The bug has been introduced in commit 5e59f7175f96550ede91f58d267d2b551cb6fbba Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Mon Jun 30 10:41:24 2014 -0700 drm/i915: Try harder to get FBC Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88975 Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't complain about stolen conflicts on gen3Daniel Vetter2014-12-101-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Apparently stuff works that way on those machines. I agree with Chris' concern that this is a bit risky but imo worth a shot in -next just for fun. Afaics all these machines have the pci resources allocated like that by the BIOS, so I suspect that it's all ok. This regression goes back to commit eaba1b8f3379b5d100bd146b9a41d28348bdfd09 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jul 4 12:28:35 2013 +0100 drm/i915: Verify that our stolen memory doesn't conflict Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76983 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71031 Tested-by: lu hua <huax.lu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Paul Menzel <paulepanter@users.sourceforge.net> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Move flags describing VMA mappings into the VMATvrtko Ursulin2014-11-041-1/+1
| | | | | | | | | | | | If these flags are on the object level it will be more difficult to allow for multiple VMAs per object. v2: Simplification and cleanup after code review comments (Chris Wilson). Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Extend BIOS stolen mem handling to all platformDaniel Vetter2014-09-191-2/+11
| | | | | | | | | | | Based upon a patch from Deepak, but reworked to only apply on gen7+ and with the logic a bit clarified. v2: Fix s/SHIFT/MASK/ fumble that Ville spotted. Cc: Deepak S <deepak.s@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.16' into drm-nextDave Airlie2014-08-051-0/+44
|\ | | | | | | | | | | | | | | | | | | Linux 3.16 backmerge requested by i915, nouveau and radeon authors Conflicts: drivers/gpu/drm/i915/i915_gem_render_state.c drivers/gpu/drm/i915/intel_drv.h
| * drm/i915: Don't clobber the GTT when it's within stolen memoryVille Syrjälä2014-07-091-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On most gen2-4 platforms the GTT can be (or maybe always is?) inside the stolen memory region. If that's the case, reduce the size of the stolen memory appropriately to make make sure we don't clobber the GTT. v2: Deal with gen4 36 bit physical address Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80151 Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Try harder to get FBCBen Widawsky2014-07-031-14/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GEN FBC unit provides the ability to set a low pass on frames it attempts to compress. If a frame is less than a certain amount compressibility (2:1, 4:1) it will not bother. This allows the driver to reduce the size it requests out of stolen memory. Unluckily, a few months ago, Ville actually began using this feature for framebuffers that are 16bpp (not sure why not 8bpp). In those cases, we are already using this mechanism for a different purpose, and so we can only achieve one further level of compression (2:1 -> 4:1) FBC GEN1, ie. pre-G45 is ignored. The cleverness of the patch is Art's. The bugs are mine. v2: Update message and including missing threshold case 3 (Spotted by Arthur). Cc: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Extract CFB threshold calculationBen Widawsky2014-07-031-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Right now, there is no threshold (0 means fail, 1 means 1:1 compression limit). This is to split the function/non-functional change of the next patch. The next patch will start to attempt to reduce the amount of CFB space we need for dire situations. It will be contained within this function. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Move compressed_fb to static allocationBen Widawsky2014-07-031-17/+10Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We are already using the size to determine whether or not to free the object, so there is no functional change there. Almost everything else has changed to static allocations of the drm_mm_node too. Aside from bringing this inline with much of our other code, this makes error paths slightly simpler, which benefits the look of an upcoming patch. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Use the .release hook to drop the stolen drm_mm trackingChris Wilson2014-06-131-10/+11
|/ | | | | | | | | Now that we have a release hook into i915_gem_object_free, we can move the explicit call to the internal stolen function and hook it up throught the callback instead. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: restrict vt-d stolen memory workaround to pre-gen8Daniel Vetter2014-03-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | We want future generations to at least attempt to use all features, so restrict the stolen memory disabling when vt-d is enabled to the latest generation we have reports for. Which is a HSW per the original report. Also once we get a bit a hold of some of the mysterious framebuffer in stolen memory issues that still haunt bugzilla, we should probably drop this hack again and see what happens. This was introduced in commit 0f4706d2740f2a221cd502922b22e522009041d9 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Mar 18 14:50:50 2014 +0200 drm/i915: Disable stolen memory when DMAR is active Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: David Woodhouse <dwmw2@infradead.org> References: https://bugs.freedesktop.org/show_bug.cgi?id=68535 Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Disable stolen memory when DMAR is activeChris Wilson2014-03-191-0/+7
| | | | | | | | | | | | | | | | We have reports of heavy screen corruption if we try to use the stolen memory reserved by the BIOS whilst the DMA-Remapper is active. This quirk may be only specific to a few machines or BIOSes, but first lets apply the big hammer and always disable use of stolen memory when DMAR is active. v2 by Jani: Rebase on -fixes, only look at intel_iommu_gfx_mapped. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68535 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Resolving the memory region conflict for Stolen areaAkash Goel2014-03-031-3/+16
| | | | | | | | | | | | | | | There is a conflict seen when requesting the kernel to reserve the physical space used for the stolen area. This is because some BIOS are wrapping the stolen area in the root PCI bus, but have an off-by-one error. As a workaround we retry the reservation with an offset of 1 instead of 0. v2: updated commit message & the comment in source file (Daniel) Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Fix the offset issue for the stolen GEM objectsAkash Goel2014-01-281-1/+1
| | | | | | | | | | | | | | | | | | | | The 'offset' field of the 'scatterlist' structure was wrongly programmed with the offset value from the base of stolen area, whereas this field indicates the offset from where the interested data starts within the first PAGE pointed to by 'scattterlist' structure. As a result when a new GEM object allocated from stolen area is mapped to GTT, it could lead to an overwrite of GTT entries as the page count calculation will go wrong, refer the function 'sg_page_count'. v2: Modified the commit message. (Chris) Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71908 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69104 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: grab a pages pin count for preallocate stolenDaniel Vetter2013-12-181-0/+1
| | | | | | | | | | | | | | | | | | But only when we indeed set up a gtt mapping. We need this since the vma also holds a pages_pin_count, on top of the unconditional pages_pin_count we grab for all stolen objects (to avoid swap-out). This should avoid a pages_pin_count underrun when cleaning up framebuffers objects taken over from the BIOS. Chris mentioned in his review that this bug even predates the vma conversion. Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.12-rc2' into drm-intel-nextDaniel Vetter2013-09-241-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge Linux 3.12-rc2 to prep for a bunch of -next patches: - Header cleanup in intel_drv.h, both changed in -fixes and my current -next pile. - Cursor handling cleanup for -next which depends upon the cursor handling fix merged into -rc2. All just trivial conflicts of the "changed adjacent lines" type: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Skip stolen region initialisation if none is reservedChris Wilson2013-09-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Paulo reported that if he set the amount of reserved memory to 0, then we emitted a warning about a conflict before disabling our use of stolen memory. This was introduced with commit eaba1b8f3379b5d100bd146b9a41d28348bdfd09 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jul 4 12:28:35 2013 +0100 drm/i915: Verify that our stolen memory doesn't conflict and is simply fixed by checking for a no reservation first. Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: inline vma_create into lookup_or_create_vmaDaniel Vetter2013-09-041-1/+1
|/ | | | | | | | | | | | | | | | | | | | | In the execbuf code we don't clean up any vmas which ended up not getting bound for code simplicity. To make sure that we don't end up creating multiple vma for the same vm kill the somewhat dangerous vma_create function and inline it into lookup_or_create. This is just a safety measure to prevent surprises in the future. Also update the somewhat confused comment in the execbuf code and clarify what kind of magic is going on with a new one. v2: Keep the function separate as requested by Chris. But give it a __ prefix for paranoia and move it tighter together with the other vma stuff. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'drm-intel-next-2013-08-23' of ↵Dave Airlie2013-08-301-5/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Need to get my stuff out the door ;-) Highlights: - pc8+ support from Paulo - more vma patches from Ben. - Kconfig option to enable preliminary support by default (Josh Triplett) - Optimized cpu cache flush handling and support for write-through caching of display planes on Iris (Chris) - rc6 tuning from Stéphane Marchesin for more stability - VECS seqno wrap/semaphores fix (Ben) - a pile of smaller cleanups and improvements all over Note that I've ditched Ben's execbuf vma conversion for 3.12 since not yet ready. But there's still other vma conversion stuff in here. * tag 'drm-intel-next-2013-08-23' of git://people.freedesktop.org/~danvet/drm-intel: (62 commits) drm/i915: Print seqnos as unsigned in debugfs drm/i915: Fix context size calculation on SNB/IVB/VLV drm/i915: Use POSTING_READ in lcpll code drm/i915: enable Package C8+ by default drm/i915: add i915.pc8_timeout function drm/i915: add i915_pc8_status debugfs file drm/i915: allow package C8+ states on Haswell (disabled) drm/i915: fix SDEIMR assertion when disabling LCPLL drm/i915: grab force_wake when restoring LCPLL drm/i915: drop WaMbcDriverBootEnable workaround drm/i915: Cleaning up the relocate entry function drm/i915: merge HSW and SNB PM irq handlers drm/i915: fix how we mask PMIMR when adding work to the queue drm/i915: don't queue PM events we won't process drm/i915: don't disable/reenable IVB error interrupts when not needed drm/i915: add dev_priv->pm_irq_mask drm/i915: don't update GEN6_PMIMR when it's not needed drm/i915: wrap GEN6_PMIMR changes drm/i915: wrap GTIMR changes drm/i915: add the FCLK case to intel_ddi_get_cdclk_freq ...
| * drm/i915: clarify error paths in create_stolen_for_preallocatedDaniel Vetter2013-08-221-2/+3
| | | | | | | | | | | | | | | | | | Use the standard inversely ordered goto label stack for everything. Spotted while reviewing place where we might need to to call vma_destroy but failed to do so. Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Allow the GPU to cache stolen memoryChris Wilson2013-08-101-3/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | As a corollary to reviewing the interaction between LLC and our cache domains, the GPU PTE bits are independent of the CPU PAT bits. As such we can set the cache level on stolen memory based on how we wish the GPU to cache accesses to it. So we are free to set the same default cache levels as for normal bo, i.e. enable LLC cacheing by default where appropriate. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge tag 'drm-intel-next-2013-08-09' of ↵Dave Airlie2013-08-211-5/+5
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: New pile of stuff for -next: - Cleanup of the old crtc helper callbacks, all encoders are now converted to the i915 modeset infrastructure. - Massive amount of wm patches from Ville for ilk, snb, ivb, hsw, this is prep work to eventually get things going for nuclear pageflips where we need to adjust watermarks on the fly. - More vm/vma patches from Ben. This refactoring isn't yet fully rolled out, we miss the execbuf conversion and some of the low-level bind/unbind support code. - Convert our hdmi infoframe code to use the new common helper functions (Damien). This contains some bugfixes for the common infoframe helpers. - Some cruft removal from Damien. - Various smaller bits&pieces all over, as usual. * tag 'drm-intel-next-2013-08-09' of git://people.freedesktop.org/~danvet/drm-intel: (105 commits) drm/i915: Fix FB WM for HSW drm/i915: expose HDMI connectors on port C on BYT drm/i915: fix a limit check in hsw_compute_wm_results() drm/i915: unbreak i915_gem_object_ggtt_unbind() drm/i915: Make intel_set_mode() static drm/i915: Remove intel_modeset_disable() drm/i915: Make intel_encoder_dpms() static drm/i915: Make i915_hangcheck_elapsed() static drm/i915: Fix #endif comment drm/i915: Remove i915_gem_object_check_coherency() drm/i915: Remove stale prototypes drm/i915: List objects allocated from stolen memory in debugfs drm/i915: Always call intel_update_sprite_watermarks() when disabling a plane drm/i915: Pass plane and crtc to intel_update_sprite_watermarks drm/i915: Don't try to disable plane if it's already disabled drm/i915: Pass crtc to our update/disable_plane hooks drm/i915: Split plane watermark parameters into a separate struct drm/i915: Pull some watermarks state into a separate structure drm/i915: Calculate max watermark levels for ILK+ drm/i915: Rename hsw_lp_wm_result to intel_wm_level ...
| * drm/i915: mm_list is per VMABen Widawsky2013-08-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | formerly: "drm/i915: Create VMAs (part 5) - move mm_list" The mm_list is used for the active/inactive LRUs. Since those LRUs are per address space, the link should be per VMx . Because we'll only ever have 1 VMA before this point, it's not incorrect to defer this change until this point in the patch series, and doing it here makes the change much easier to understand. Shamelessly manipulated out of Daniel: "active/inactive stuff is used by eviction when we run out of address space, so needs to be per-vma and per-address space. Bound/unbound otoh is used by the shrinker which only cares about the amount of memory used and not one bit about in which address space this memory is all used in. Of course to actual kick out an object we need to unbind it from every address space, but for that we have the per-object list of vmas." v2: only bump GGTT LRU in i915_gem_object_set_to_gtt_domain (Chris) v3: Moved earlier in the series v4: Add dropped message from v3 Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Frob patch to apply and use vma->node.size directly as discused with Ben. Also drop a needles BUG_ON before move_to_inactive, the function itself has the same check.] [danvet 2nd: Rebase on top of the lost "drm/i915: Cleanup more of VMA in destroy", specifically unlink the vma from the mm_list in vma_unbind (to keep it symmetric with bind_to_vm) instead of vma_destroy.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Use ggtt_vm to save some typingBen Widawsky2013-08-051-5/+5
| | | | | | | | | | | | | | | | Just some small cleanups, and a rename of vm->ggtt_vm requested by Daniel. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge tag 'drm-intel-next-2013-07-26-fixed' of ↵Dave Airlie2013-08-071-38/+30Star
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Neat that QA (and Ben) keeps on humming along while I'm on vacation, so you already get the next feature pull request: - proper eLLC support for HSW from Ben - more interrupt refactoring - add w/a tags where we implement them already (Damien) - hangcheck fixes (Chris) + hangcheck stats (Mika) - flesh out the new vm structs for ppgtt and ggtt (Ben) - PSR for Haswell, still disabled by default (Rodrigo et al.) - pc8+ refclock sequence code from Paulo - more interrupt refactoring from Paulo, unifying ilk/snb with the ivb/hsw interrupt code - full solution for the Haswell concurrent reg access issues (Chris) - fix racy object accounting, used by some new leak tests - fix sync polarity settings on ch7xxx dvo encoder - random bits&pieces, little fixes and better debug output all over [airlied: fix conflict with drm_mm cleanups] * tag 'drm-intel-next-2013-07-26-fixed' of git://people.freedesktop.org/~danvet/drm-intel: (289 commits) drm/i915: Do not dereference NULL crtc or fb until after checking drm/i915: fix pnv display core clock readout out drm/i915: Replace open-coded offset_in_page() drm/i915: Retry DP aux_ch communications with a different clock after failure drm/i915: Add messages useful for HPD storm detection debugging (v2) drm/i915: dvo_ch7xxx: fix vsync polarity setting drm/i915: fix the racy object accounting drm/i915: Convert the register access tracepoint to be conditional drm/i915: Squash gen lookup through multiple indirections inside GT access drm/i915: Use the common register access functions for NOTRACE variants drm/i915: Use a private interface for register access within GT drm/i915: Colocate all GT access routines in the same file drm/i915: fix reference counting in i915_gem_create drm/i915: Use Graphics Base of Stolen Memory on all gen3+ drm/i915: disable stolen mem for OVERLAY_NEEDS_PHYSICAL drm/i915: add functions to disable and restore LCPLL drm/i915: disable CLKOUT_DP when it's not needed drm/i915: extend lpt_enable_clkout_dp drm/i915: fix up error cleanup in i915_gem_object_bind_to_gtt drm/i915: Add some debug breadcrumbs to connector detection ...
| * Merge commit 'Merge branch 'drm-fixes' of ↵Daniel Vetter2013-07-251-3/+6
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~airlied/linux' This backmerges Linus' merge commit of the latest drm-fixes pull: commit 549f3a1218ba18fcde11ef0e22b07e6365645788 Merge: 42577ca 058ca4a Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Jul 23 15:47:08 2013 -0700 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux We've accrued a few too many conflicts, but the real reason is that I want to merge the 100% solution for Haswell concurrent registers writes into drm-intel-next. But that depends upon the 90% bandaid merged into -fixes: commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jul 19 20:36:51 2013 +0100 drm/i915: Serialize almost all register access Also, we can roll up on accrued conflicts. Usually I'd backmerge a tagged -rc, but I want to get this done before heading off to vacations next week ;-) Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/i915_gem.c v2: For added hilarity we have a init sequence conflict around the gt_lock, so need to move that one, too. Spotted by Jani Nikula. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Use Graphics Base of Stolen Memory on all gen3+Chris Wilson2013-07-241-30/+12Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So I made the mistake of missing that the desktop and mobile chipsets have different layouts in their PCI configurations, and we were incorrectly setting the wrong physical address for stolen memory on mobile chipsets. Since all gen3+ are actually consistent in the location of the GBSM register in the PCI configuration space on device 2 (the GPU), use it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> [danvet: Drop cc: stable and fudge conflicts.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: checking for NULL instead of IS_ERR()Dan Carpenter2013-07-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | i915_gem_vma_create() returns and ERR_PTR() or a valid pointer, it never returns NULL. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Create VMAsBen Widawsky2013-07-181-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Formerly: "drm/i915: Create VMAs (part 1)" In a previous patch, the notion of a VM was introduced. A VMA describes an area of part of the VM address space. A VMA is similar to the concept in the linux mm. However, instead of representing regular memory, a VMA is backed by a GEM BO. There may be many VMAs for a given object, one for each VM the object is to be used in. This may occur through flink, dma-buf, or a number of other transient states. Currently the code depends on only 1 VMA per object, for the global GTT (and aliasing PPGTT). The following patches will address this and make the rest of the infrastructure more suited v2: s/i915_obj/i915_gem_obj (Chris) v3: Only move an object to the now global unbound list if there are no more VMAs for the object which are bound into a VM (ie. the list is empty). v4: killed obj->gtt_space some reworks due to rebase v5: Free vma on error path (Imre) v6: Another missed vma free in i915_gem_object_bind_to_gtt error path (Imre) Fixed vma freeing in stolen preallocation (Imre) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Squash in fixup from Ben to not deref a non-existing vma in set_cache_level, reported by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Free stolen node on failed preallocationBen Widawsky2013-07-171-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | The odds of this happening are *extremely* unlikely. Reported-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Move active/inactive lists to new mmBen Widawsky2013-07-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Shamelessly manipulated out of Daniel :-) "When moving the lists around explain that the active/inactive stuff is used by eviction when we run out of address space, so needs to be per-vma and per-address space. Bound/unbound otoh is used by the shrinker which only cares about the amount of memory used and not one bit about in which address space this memory is all used in. Of course to actual kick out an object we need to unbind it from every address space, but for that we have the per-object list of vmas." v2: Leave the bound list as a global one. (Chris, indirectly) v3: Rebased with no i915_gtt_vm. In most places I added a new *vm local, since it will eventually be replaces by a vm argument. Put comment back inline, since it no longer makes sense to do otherwise. v4: Rebased on hangcheck/error state movement Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Put the mm in the parent address spaceBen Widawsky2013-07-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Every address space should support object allocation. It therefore makes sense to have the allocator be part of the "superclass" which GGTT and PPGTT will derive. Since our maximum address space size is only 2GB we're not yet able to avoid doing allocation/eviction; but we'd hope one day this becomes almost irrelvant. v2: Rebased Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-12 09:11:51 +0200