[pull] amdgpu, amdkfd, radeon drm-next-5.3
Hi Dave, Daniel, Last round of updates for 5.3. The big one here is navi10 support. The rest is just a few other odds and ends. My first shot at annotated tags. The following changes since commit 561564bea3248293398dc32ec36da40fb71faed0: Merge tag 'omapdrm-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next (2019-06-11 13:29:33 +0200) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.3-2019-06-22 for you to fetch changes up to f3f48d7331cf5ad9a6b3a6beff38f3dad1871b49: drm/amdgpu: drop unused df init callback (2019-06-22 09:34:14 -0500) drm-next-5.3-2019-06-22: amdgpu: - SR-IOV L1 policy fixes - Removed no longer needed vram_page_split module parameter - Add module parameter to override default ABM level - Gamma fixes - No need to check return values for debugfs - Improve HMM error handling - Avoid possible OOM situations when lots of thread are submitting with memory contention - Improve hw i2c access abritration - DSC (Display Stream Compression) support in DC - Initial navi10 support * DC support * GFX/Compute support * SDMA support * Power Management support * VCN support amdkfd: - Implement priority controls for gfx9 - Enable VEGAM - Rework mqd allocation and init - Circular locking fix - Fix SDMA queue allocation race condition - No need to check return values for debugfs - Add proc style process information - Initial navi10 support radeon: - No need to check return values for debugfs UAPI changes: - GDDR6 added to vram type query - New Navi10 details added gpu info query - Navi family added to asic family query Aidan Wood (2): drm/amd/display: Properly set DCF clock drm/amd/display: Properly set u clock Alex Deucher (17): drm/amdgpu: return 0 by default in amdgpu_pm_load_smu_firmware drm/amdgpu: wait to fetch the vbios until after common init Revert "drm/amd/display: make clk_mgr call enable_pme_wa" Revert "drm/amd/display: Add Underflow Asserts to dc" Revert "drm/amd/display: move vmid determination logic out of dc" Revert "drm/amd/display: Rework CRTC color management" Revert "drm/amd/display: Use macro for invalid OPP ID" Revert "drm/amd/display: Copy stream updates onto streams" drm/amdgpu: add Navi10 pci ids drm/amd/powerplay/smu11: remove smu_update_table_with_arg drm/amdgpu/powerplay: add license to smu11 header drm/amdgpu/powerplay/vega20: use correct table index drm/amdgpu/gfx10: update to latest golden setting drm/amd/display: add fast_validate parameter to dcn20_validate_bandwidth drm/amd/display: updates for dcn20_update_bandwidth drm/amd/display: update dcn2 dc_plane_cap drm/amdgpu: drop unused df init callback Anthony Koo (2): drm/amd/display: fix issue with eDP not detected on driver load drm/amd/display: do not power on eDP power rail early Aric Cyr (4): drm/amd/display: 3.2.33 drm/amd/display: 3.2.34 drm/amd/display: 3.2.35 drm/amd/display: Intermittent DCN2 pipe hang on mode change Arnd Bergmann (1): drm/amdgpu: fix error handling in df_v3_6_pmc_start Bob Yang (1): drm/amd/display: fixed DCC corruption Charlene Liu (15): drm/amd/display: add some math functions for dcn_calc_math drm/amd/display: add audio related regs drm/amd/display: dcn2 dmcu wait_for_loop update with dispclk. drm/amd/display: fix can not turn on two displays due to DSC_RESOURCE failed. drm/amd/display: Add hubp_init entry to hubp vtable drm/amd/display: add SW_USE_I2C_REG request. drm/amd/display: Create DWB resource for DCN2 drm/amd/display: [backport] dwb dm + efc support drm/amd/display: used optimum VSTARTUP instead of MaxVStartup drm/amd/display: Return UPDATE_TYPE_FULL on writeback update drm/amd/display: add some parameters to validate bandwidth functions drm/amd/display: add dwb stere caps and version drm/amd/display: add p010 and ayuv plane caps drm/amd/display: dcn2 use fixed clocks. drm/amd/display: expose dentist_get_did_from_divider Chengming Gui (1): drm/amd/powerplay: add set_power_profile_mode for raven1_refresh Chris Park (2): drm/amd/display: Clean up scdc_test_data struct drm/amd/display: Move link functions from dc to dc_link Christian König (4): drm/amdgpu: drop some validation failure messages drm/amdgpu: create GDS, GWS and OA in system domain drm/amdgpu: stop removing BOs from the LRU v3 drm/amdgpu: disable concurrent flushes for Navi10 v2 Dan Carpenter (1): drm/amdgpu: Fix bounds checking in amdgpu_ras_is_supported() Derek Lai (1): drm/amd/display: add i2c_hw_Status check to make sure as HW I2c in use Dmytro Laktyushkin (10):
Re: [PATCH] drm/fourcc: Add Arm 16x16 block modifier
On Fri, Jun 21, 2019 at 11:27 PM Daniel Vetter wrote:
>
> On Fri, Jun 21, 2019 at 12:21 PM Raymond Smith wrote:
> >
> > Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
> > denote the 16x16 block u-interleaved format used in Arm Utgard and
> > Midgard GPUs.
> >
> > Signed-off-by: Raymond Smith
> > ---
> > include/uapi/drm/drm_fourcc.h | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 3feeaa3..8ed7ecf 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -743,6 +743,16 @@ extern "C" {
> > #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
> >
> > /*
> > + * Arm 16x16 Block U-Interleaved modifier
> > + *
> > + * This is used by Arm Mali Utgard and Midgard GPUs. It divides the image
> > + * into 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
> > + * in the block are reordered.
> > + */
> > +#define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \
> > + fourcc_mod_code(ARM, ((1ULL << 55) | 1))
>
Thanks for the patch.
> This seems to be an extremely random pick for a new number. What's the
> thinking here? Aside from "doesnt match any of the afbc combos" ofc.
> If you're already up to having thrown away 55bits, then it's not going
> to last long really :-)
>
> I think a good idea would be to reserve a bunch of the high bits as
> some form of index (afbc would get index 0 for backwards compat). And
> then the lower bits would be for free use for a given index/mode. And
> the first mode is probably an enumeration, where possible modes simple
> get enumerated without further flags or anything.
>
This idea is like my previous patch:
https://patchwork.kernel.org/patch/10852619/
lima driver just need a unique modifier to represent this format, so this patch
is enough for lima needs.
But I'm also a little worry about the expansion of only reserve the top bit
(55) for classification from the ARM point of view. A few more bit (at least 2
for being able to represent 4 class of format) and more clear class/format
fields division would be better.
Thanks,
Qiang
>
> Also ofc needs acks from lima/panfrost people since I assume they'll
> be using this, too.
>
> Thanks, Daniel
>
> > +
> > +/*
> > * Allwinner tiled modifier
> > *
> > * This tiling mode is implemented by the VPU found on all Allwinner
> > platforms,
> > --
> > 2.7.4
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [PATCH v2 1/4] drm/lima: Mark 64-bit number as ULL to silence Smatch warning
Thanks. This patch series are: Reviewed-by: Qiang Yu I'll apply them to drm-misc-next. Regards, Qiang On Sat, Jun 22, 2019 at 12:21 AM Krzysztof Kozlowski wrote: > > Mark long numbers with ULL to silence the Smatch warning: > > drivers/gpu/drm/lima/lima_device.c:314:32: warning: constant 0x1 > is so big it is long long > > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Qiang Yu > > --- > > Changes since v1: > 1. Add reviewed-by tag > --- > drivers/gpu/drm/lima/lima_vm.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/lima/lima_vm.h b/drivers/gpu/drm/lima/lima_vm.h > index caee2f8a29b4..e0bdedcf14dd 100644 > --- a/drivers/gpu/drm/lima/lima_vm.h > +++ b/drivers/gpu/drm/lima/lima_vm.h > @@ -15,9 +15,9 @@ > #define LIMA_VM_NUM_PT_PER_BT (1 << LIMA_VM_NUM_PT_PER_BT_SHIFT) > #define LIMA_VM_NUM_BT (LIMA_PAGE_ENT_NUM >> LIMA_VM_NUM_PT_PER_BT_SHIFT) > > -#define LIMA_VA_RESERVE_START 0xFFF0 > +#define LIMA_VA_RESERVE_START 0x0FFF0ULL > #define LIMA_VA_RESERVE_DLBU LIMA_VA_RESERVE_START > -#define LIMA_VA_RESERVE_END0x1 > +#define LIMA_VA_RESERVE_END0x1ULL > > struct lima_device; > > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110971] GPU HANG: ecode 6:1:0xfffffffe, in spring-main [8656], hang on rcs0
https://bugs.freedesktop.org/show_bug.cgi?id=110971 Bug ID: 110971 Summary: GPU HANG: ecode 6:1:0xfffe, in spring-main [8656], hang on rcs0 Product: Mesa Version: 19.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/DRI/i915 Assignee: dri-devel@lists.freedesktop.org Reporter: chris.rebisc...@archlinux.org QA Contact: dri-devel@lists.freedesktop.org Created attachment 144614 --> https://bugs.freedesktop.org/attachment.cgi?id=144614=edit crash dump from /sys/class/drm/card0/error I get unspecified GPU hangs while playing games. It mostly occurs when my CPU starts throttling: [ 5838.889104] mce: CPU0: Package temperature above threshold, cpu clock throttled (total events = 100749) [ 5838.889108] mce: CPU2: Package temperature above threshold, cpu clock throttled (total events = 100749) [ 5838.889110] mce: CPU3: Package temperature above threshold, cpu clock throttled (total events = 100749) [ 5838.889112] mce: CPU1: Package temperature above threshold, cpu clock throttled (total events = 100749) [ 5900.819612] mce: CPU2: Core temperature above threshold, cpu clock throttled (total events = 16235) [ 5900.819613] mce: CPU3: Core temperature above threshold, cpu clock throttled (total events = 16235) [ 5900.827685] mce: CPU2: Core temperature/speed normal [ 5900.827686] mce: CPU3: Core temperature/speed normal [ 6138.891505] mce: CPU1: Package temperature above threshold, cpu clock throttled (total events = 171156) [ 6138.891506] mce: CPU0: Package temperature above threshold, cpu clock throttled (total events = 171156) [ 6138.891528] mce: CPU2: Package temperature above threshold, cpu clock throttled (total events = 171156) [ 6138.891529] mce: CPU3: Package temperature above threshold, cpu clock throttled (total events = 171156) [ 6176.479565] i915 :00:02.0: GPU HANG: ecode 6:1:0xfffe, in spring-main [8656], hang on rcs0 [ 6176.479570] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 6176.479572] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [ 6176.479573] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 6176.479574] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 6176.479575] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 6176.479642] i915 :00:02.0: Resetting chip for hang on rcs0 [ 6422.644956] i915 :00:02.0: Resetting chip for hang on rcs0 [ 6438.888919] mce: CPU3: Package temperature/speed normal [ 6438.888920] mce: CPU2: Package temperature/speed normal [ 6438.888924] mce: CPU1: Package temperature/speed normal [ 6438.888926] mce: CPU0: Package temperature/speed normal -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] dt-bindings: display: msm: gmu: add optional ocmem property
On Thu, Jun 20, 2019 at 7:14 PM Brian Masney wrote:
>
> On Wed, Jun 19, 2019 at 01:21:20PM -0700, Rob Clark wrote:
> > On Wed, Jun 19, 2019 at 1:17 PM Rob Herring wrote:
> > >
> > > On Sun, Jun 16, 2019 at 7:29 AM Brian Masney
> > > wrote:
> > > >
> > > > Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> > > > must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> > > > optional ocmem property to the Adreno Graphics Management Unit bindings.
> > > >
> > > > Signed-off-by: Brian Masney
> > > > ---
> > > > Documentation/devicetree/bindings/display/msm/gmu.txt | 4
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > > b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > > index 90af5b0a56a9..c746b95e95d4 100644
> > > > --- a/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > > +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > > @@ -31,6 +31,10 @@ Required properties:
> > > > - iommus: phandle to the adreno iommu
> > > > - operating-points-v2: phandle to the OPP operating points
> > > >
> > > > +Optional properties:
> > > > +- ocmem: phandle to the On Chip Memory (OCMEM) that's present on some
> > > > Snapdragon
> > > > + SoCs. See
> > > > Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml.
> > >
> > > We already have a couple of similar properties. Lets standardize on
> > > 'sram' as that is what TI already uses.
> > >
> > > Also, is the whole OCMEM allocated to the GMU? If not you should have
> > > child nodes to subdivide the memory.
> > >
> >
> > iirc, downstream a large chunk of OCMEM is statically allocated for
> > GPU.. the remainder is dynamically allocated for different use-cases.
> > The upstream driver Brian is proposing only handles the static
> > allocation case
>
> It appears that the GPU expects to use a specific region of ocmem,
> specifically starting at 0. The freedreno driver allocates 1MB of
> ocmem on the Nexus 5 starting at ocmem address 0. As a test, I
> changed the starting address to 0.5MB and kmscube shows only half the
> cube, and four wide black bars across the screen:
>
> https://www.flickr.com/photos/masneyb/48100534381/
>
> > (and I don't think we have upstream support for the various audio and
> > video use-cases that used dynamic OCMEM allocation downstream)
>
> That's my understanding as well.
>
> > Although maybe we should still have a child node to separate the
> > statically and dynamically allocated parts? I'm not sure what would
> > make the most sense..
>
> Given that the GPU is expecting a fixed address in ocmem, perhaps it
> makes sense to have the child node. How about this based on the
> sram/sram.txt bindings?
>
> ocmem: ocmem@fdd0 {
> compatible = "qcom,msm8974-ocmem";
>
> reg = <0xfdd0 0x2000>, <0xfec0 0x18>;
> reg-names = "ctrl", "mem";
>
> clocks = < RPM_SMD_OCMEMGX_CLK>, < OCMEMCX_OCMEMNOC_CLK>;
> clock-names = "core", "iface";
>
> gmu-sram@0 {
> reg = <0x0 0x10>;
> pool;
> };
>
> misc-sram@0 {
> reg = <0x10 0x08>;
> export;
> };
> };
>
> I marked the misc pool as export since I've seen in the downstream ocmem
> sources a reference to their closed libsensors that runs in userspace.
>
> Looking at the sram bindings led me to the genalloc API
> (Documentation/core-api/genalloc.rst). I wonder if this is the way that
> this should be done?
won't claim to be a dt expert, but this seems somewhat sane.. maybe
drop the export until a use-case comes along for that.. or even the
entire second child node? I guess that comes down to what robher and
others prefer, I can't really speculate too much about the non-gpu
use-cases for ocmem (or if they'll ever be upstream)
BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/18] drm/ttm: make ttm bo a gem bo subclass
Hi, Daniel,
On 6/22/19 11:18 AM, Daniel Vetter wrote:
Hi Thomas,
On Sat, Jun 22, 2019 at 12:52 AM Thomas Hellstrom wrote:
On 6/21/19 5:57 PM, Daniel Vetter wrote:
On Fri, Jun 21, 2019 at 05:12:19PM +0200, Thomas Hellström (VMware) wrote:
On 6/21/19 1:57 PM, Gerd Hoffmann wrote:
Aargh. Please don't do this. Multiple reasons:
1) I think It's bad to dump all buffer object functionality we can possibly
think of in a single struct and force that on all (well at least most)
users. It's better to isolate functionality in structs, have utility
functions for those and let the drivers derive their buffer objects from
whatever functionality they actually need.
2) vmwgfx is not using gem and we don't want to carry that extra payload in
the buffer object.
3) TTM historically hasn't been using the various drm layers except for
later when common helpers have been used, (like the vma manager and the
cache utilities). It's desirable to keep that layer distinction. (which is
really what I'm saying in 1.)
Now if more and more functionality that originated in TTM is moving into GEM
we need to find a better way to do that without duplicating functionality. I
suggest adding pointers in the TTM structs and defaulting those pointers to
the member in the TTM struct. Optionally to to the member in the GEM struct.
If we need to migrate those members out of the TTM struct, vmwgfx would have
to provide them in its own buffer class.
NAK from the vmwgfx side.
It's 59 DRIVER_GEM vs 1 which is not. I think the verdict is clear what
the reasonable thing to do is here, and this will allow us to
substantially improve code and concept sharing across drm drivers.
10 years ago it was indeed not clear whether everyone doing the same is a
bright idea, but that's no more. If you want I guess you can keep a
private copy of ttm in vmwgfx, but not sure that's really worth it
long-term.
-Daniel
It's not a question about whether GEM or TTM, or even the number of
drivers using one or the other. (GEM would actually be a good choice for
the latter vmwgfx device versions). But this is going against all recent
effort to make different parts of drm functionality recently self-contained.
Just stop and think for a while what would happen if someone would
suggest doing the opposite: making a gem object a derived class of a TTM
object, arguing that a lot of GEM drivers are using TTM as a backend.
There would probably be a lot of people claiming "we don't want to
unnecesarily carry that stuff". That's because that would also be a poor
design.
That case is a bit a different case. We have
- 5 ttm+gem drivers, recently refactored into vram helpers (but still
ttm underneath)
- 5 ttm+gem drivers, using ttm directly
- 1 ttm driver, no gem
- 48 other gem drivers with no vram support
- 1 gem driver which will gain vram support shortly, with or without
ttm still not clear
11:48 is not even close to 59:1 imo. And I think even if Thomas
Zimmermann and others get really busy porting old discrete fbdev
drivers to kms, that ratio won't change much since we're also gaining
new soc drm drivers at a steady rate.
Yeah, my point was not really suggesting that we do this, but rather
that people would rightfully get upset because the struct contains
unused stuff.
Also a trap we might end up with in the future is that with the design
suggested in this patch series is that people start assuming that the
embedded gem object is actually initialized and working, which could
lead to pretty severe problems for vmwgfx...
Also I wouldn't mind if we e.g. stuff a struct list_head lru; into
drm_gem_buffer_object, that's probably useful for many cases (not the
pure display drivers, but they tend to have so few bo it really wont
matter even if we add a few kb of cruft).
What I'm suggesting is, build that improved code and concept sharing around
struct gem_ttm_object {
struct gem_object;
struct ttm_object;
};
I guess technically this would work too. Bit more churn (maybe
substantially more, I haven't looked tbh) to roll this out for all the
ttm drivers using gem.
And lets work toghether to eliminate what's duplicated.
How would you share the bo.resv pointer with the above design? With
embedding ttm can use the gem one, and we drop a bunch of code (and
for all the ttm+gem drivers, one pointer they don't need twice). With
the side-by-side, which is the design all gem+ttm drivers used the
past few years, we still need that duplication. Same for the vma node
thing, which is also duplicated.
To bemore precise I'd probably define a
struct drm_bo_common {
struct reservation_object r;
struct drm_vma_node v;
};
Embed it in a struct drm_gem_object (and in a struct
vmwgfx_buffer_object) and then have a pointer to a struct drm_bo_common
in the struct ttm_buffer_object. That's a single pointer overhead for
everything we want to move.
As TTM-specific code disappears, so will the number of members in struct
drm_bo_common. Meanwhile, we maintain a
[PATCH libdrm] util: fix include path for drm_mode.h
Signed-off-by: Ilia Mirkin
---
tests/util/pattern.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/util/pattern.h b/tests/util/pattern.h
index 424b0e19..ea38cafd 100644
--- a/tests/util/pattern.h
+++ b/tests/util/pattern.h
@@ -26,7 +26,7 @@
#ifndef UTIL_PATTERN_H
#define UTIL_PATTERN_H
-#include
+#include
enum util_fill_pattern {
UTIL_PATTERN_TILES,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: fix bogus GPL-2 license header
Acked-by: Karol Herbst On Fri, Jun 21, 2019 at 8:12 PM Emil Velikov wrote: > > On 2019/06/19, Ilia Mirkin wrote: > > The bulk SPDX addition made all these files into GPL-2.0 licensed files. > > However the remainder of the project is MIT-licensed, these files > > (primarily header files) were simply missing the boiler plate and got > > caught up in the global update. > > > > Fixes: b24413180f5 (License cleanup: add SPDX GPL-2.0 license identifier to > > files with no license) > > Signed-off-by: Ilia Mirkin > > --- > > > > Ben, you did like 99.7% of this work, so ultimately your call. Pretty > > much all of these were split out from other MIT-licensed files, and most > > are header files anyways. > > > All of my glorious 23 patches to nouveau are meant to be under MIT. > Acked-by: Emil Velikov > > > Another change might be to add the SPDX identifier to files *with* > > the MIT boilerplate, but I didn't want to do too much here. > > > No objections on my end :-) > > -Emil > > ___ > Nouveau mailing list > nouv...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110968, which changed state. Bug 110968 Summary: Allow ubuntu users to install on other ubuntu versions https://bugs.freedesktop.org/show_bug.cgi?id=110968 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110968] Allow ubuntu users to install on other ubuntu versions
https://bugs.freedesktop.org/show_bug.cgi?id=110968 Eric Engestrom changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #2 from Eric Engestrom --- TIL AMD does its support via our bugzilla... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110967] Naming packages with pro suffix depending if open or close source
https://bugs.freedesktop.org/show_bug.cgi?id=110967 Eric Engestrom changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #2 from Eric Engestrom --- TIL AMD does its support via our bugzilla... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110959] Broken link to Homepage of some packages
https://bugs.freedesktop.org/show_bug.cgi?id=110959 Eric Engestrom changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #2 from Eric Engestrom --- TIL AMD does its support via our bugzilla... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110963, which changed state. Bug 110963 Summary: Wrong condition and wrong variable substitution in libgl1-amdgpu-mesa-dri in postinst script https://bugs.freedesktop.org/show_bug.cgi?id=110963 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110961] Are provided libdrm packages completely open source?
https://bugs.freedesktop.org/show_bug.cgi?id=110961 Eric Engestrom changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from Eric Engestrom --- TIL AMD does its support via our bugzilla... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110967, which changed state. Bug 110967 Summary: Naming packages with pro suffix depending if open or close source https://bugs.freedesktop.org/show_bug.cgi?id=110967 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110960] Non-existent alternative dependencies in some deb packages
https://bugs.freedesktop.org/show_bug.cgi?id=110960 Eric Engestrom changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #2 from Eric Engestrom --- TIL AMD does its support via our bugzilla... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110964] Documentation update about provided Open Vulkan implementation
https://bugs.freedesktop.org/show_bug.cgi?id=110964 Eric Engestrom changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #2 from Eric Engestrom --- TIL AMD does its support via our bugzilla... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110957, which changed state. Bug 110957 Summary: wsa-amdgpu package has empty copyright file https://bugs.freedesktop.org/show_bug.cgi?id=110957 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110962, which changed state. Bug 110962 Summary: Wrong dependencies cause force dependency on amdgpu-dkms https://bugs.freedesktop.org/show_bug.cgi?id=110962 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110960, which changed state. Bug 110960 Summary: Non-existent alternative dependencies in some deb packages https://bugs.freedesktop.org/show_bug.cgi?id=110960 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110959, which changed state. Bug 110959 Summary: Broken link to Homepage of some packages https://bugs.freedesktop.org/show_bug.cgi?id=110959 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110965] Documentation update about not provided PX package
https://bugs.freedesktop.org/show_bug.cgi?id=110965 Eric Engestrom changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from Eric Engestrom --- TIL AMD does its support via our bugzilla... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110964, which changed state. Bug 110964 Summary: Documentation update about provided Open Vulkan implementation https://bugs.freedesktop.org/show_bug.cgi?id=110964 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110961, which changed state. Bug 110961 Summary: Are provided libdrm packages completely open source? https://bugs.freedesktop.org/show_bug.cgi?id=110961 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110962] Wrong dependencies cause force dependency on amdgpu-dkms
https://bugs.freedesktop.org/show_bug.cgi?id=110962 Eric Engestrom changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from Eric Engestrom --- TIL AMD does its support via our bugzilla... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110965, which changed state. Bug 110965 Summary: Documentation update about not provided PX package https://bugs.freedesktop.org/show_bug.cgi?id=110965 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110957] wsa-amdgpu package has empty copyright file
https://bugs.freedesktop.org/show_bug.cgi?id=110957 Eric Engestrom changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #2 from Eric Engestrom --- TIL AMD does its support via our bugzilla... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110963] Wrong condition and wrong variable substitution in libgl1-amdgpu-mesa-dri in postinst script
https://bugs.freedesktop.org/show_bug.cgi?id=110963 Eric Engestrom changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #2 from Eric Engestrom --- TIL AMD does its support via our bugzilla... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] drm/vmwgfx: drop use of drmP.h in header files
Hi Sam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc5 next-20190621]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sam-Ravnborg/drm-vmwgfx-drop-use-of-drmP-h-in-header-files/20190622-234524
config: i386-randconfig-x010-201924 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
drivers/gpu//drm/vmwgfx/vmwgfx_mob.c: In function 'vmw_mob_build_pt':
>> drivers/gpu//drm/vmwgfx/vmwgfx_mob.c:517:22: error: implicit declaration of
>> function 'kmap_atomic'; did you mean 'in_atomic'?
>> [-Werror=implicit-function-declaration]
save_addr = addr = kmap_atomic(page);
^~~
in_atomic
>> drivers/gpu//drm/vmwgfx/vmwgfx_mob.c:517:20: warning: assignment makes
>> pointer from integer without a cast [-Wint-conversion]
save_addr = addr = kmap_atomic(page);
^
>> drivers/gpu//drm/vmwgfx/vmwgfx_mob.c:526:3: error: implicit declaration of
>> function 'kunmap_atomic'; did you mean 'in_atomic'?
>> [-Werror=implicit-function-declaration]
kunmap_atomic(save_addr);
^
in_atomic
cc1: some warnings being treated as errors
vim +517 drivers/gpu//drm/vmwgfx/vmwgfx_mob.c
3530bdc3 Thomas Hellstrom 2012-11-21 491
3530bdc3 Thomas Hellstrom 2012-11-21 492 /*
3530bdc3 Thomas Hellstrom 2012-11-21 493 * vmw_mob_build_pt - Build a
pagetable
3530bdc3 Thomas Hellstrom 2012-11-21 494 *
0fd53cfb Thomas Hellstrom 2013-10-24 495 * @data_addr: Array of DMA
addresses to the underlying buffer
3530bdc3 Thomas Hellstrom 2012-11-21 496 * object's data
pages.
3530bdc3 Thomas Hellstrom 2012-11-21 497 * @num_data_pages: Number of buffer
object data pages.
3530bdc3 Thomas Hellstrom 2012-11-21 498 * @pt_pages: Array of page
pointers to the page table pages.
3530bdc3 Thomas Hellstrom 2012-11-21 499 *
3530bdc3 Thomas Hellstrom 2012-11-21 500 * Returns the number of page table
pages actually used.
3530bdc3 Thomas Hellstrom 2012-11-21 501 * Uses atomic kmaps of highmem
pages to avoid TLB thrashing.
3530bdc3 Thomas Hellstrom 2012-11-21 502 */
0fd53cfb Thomas Hellstrom 2013-10-24 503 static unsigned long
vmw_mob_build_pt(struct vmw_piter *data_iter,
3530bdc3 Thomas Hellstrom 2012-11-21 504
unsigned long num_data_pages,
0fd53cfb Thomas Hellstrom 2013-10-24 505
struct vmw_piter *pt_iter)
3530bdc3 Thomas Hellstrom 2012-11-21 506 {
3530bdc3 Thomas Hellstrom 2012-11-21 507 unsigned long pt_size =
num_data_pages * VMW_PPN_SIZE;
3530bdc3 Thomas Hellstrom 2012-11-21 508 unsigned long num_pt_pages =
DIV_ROUND_UP(pt_size, PAGE_SIZE);
0fd53cfb Thomas Hellstrom 2013-10-24 509 unsigned long pt_page;
b9eb1a61 Thomas Hellstrom 2015-04-02 510 u32 *addr, *save_addr;
3530bdc3 Thomas Hellstrom 2012-11-21 511 unsigned long i;
0fd53cfb Thomas Hellstrom 2013-10-24 512 struct page *page;
3530bdc3 Thomas Hellstrom 2012-11-21 513
3530bdc3 Thomas Hellstrom 2012-11-21 514 for (pt_page = 0; pt_page <
num_pt_pages; ++pt_page) {
0fd53cfb Thomas Hellstrom 2013-10-24 515 page =
vmw_piter_page(pt_iter);
0fd53cfb Thomas Hellstrom 2013-10-24 516
0fd53cfb Thomas Hellstrom 2013-10-24 @517 save_addr = addr =
kmap_atomic(page);
3530bdc3 Thomas Hellstrom 2012-11-21 518
3530bdc3 Thomas Hellstrom 2012-11-21 519 for (i = 0; i <
PAGE_SIZE / VMW_PPN_SIZE; ++i) {
f2a0dcb1 Thomas Hellstrom 2014-01-15 520
vmw_mob_assign_ppn(,
f2a0dcb1 Thomas Hellstrom 2014-01-15 521
vmw_piter_dma_addr(data_iter));
0fd53cfb Thomas Hellstrom 2013-10-24 522 if
(unlikely(--num_data_pages == 0))
3530bdc3 Thomas Hellstrom 2012-11-21 523 break;
0fd53cfb Thomas Hellstrom 2013-10-24 524
WARN_ON(!vmw_piter_next(data_iter));
3530bdc3 Thomas Hellstrom 2012-11-21 525 }
3530bdc3 Thomas Hellstrom 2012-11-21 @526
kunmap_atomic(save_addr);
0fd53cfb Thomas Hellstrom 2013-10-24 527 vmw_piter_next(pt_iter);
3530bdc3 Thomas Hellstrom 2012-11-21 528 }
3530bdc3 Thomas Hellstrom 2012-11-21 529
3530bdc3 Thomas Hellstrom 2012-11-21 530 return num_pt_pages;
3530bdc3 Thomas Hellstrom 2012-11-21 531 }
3530bdc3 Thomas Hellstrom 2012-11-21 532
:: The code at line 517 was first introduced by commi
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 --- Comment #6 from Eric Engestrom --- (In reply to Ilia Mirkin from comment #5) > I think it's the right bugracker. Note that DRM/AMDgpu-pro component. It's > meant for the AMD developers who very much have control (or at least > influence) over these things. Something just dawned on me: as amdgpu-pro is closed source, is it only ever distributed as ubuntu packages, and therefore AMD are the ones making these packages? If so, I think I need to apologize, and all your bugs can be re-opened, sorry :/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 --- Comment #5 from Ilia Mirkin --- (In reply to Eric Engestrom from comment #3) > I'll close the ones that are clearly something the Ubuntu packager needs to > do as INVALID; I hope you don't take it badly, this was just the wrong bug > tracker ;) I think it's the right bugracker. Note that DRM/AMDgpu-pro component. It's meant for the AMD developers who very much have control (or at least influence) over these things. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110961] Are provided libdrm packages completely open source?
https://bugs.freedesktop.org/show_bug.cgi?id=110961 Andre Klapper changed: What|Removed |Added Summary|Are provoded libdrm |Are provided libdrm |packages completely open|packages completely open |source? |source? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107559] no color format choice in amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=107559 --- Comment #6 from x0a.c...@gmail.com --- Same problem. Disabling DisplayCore gets me crisp and beautiful colors, but at the cost of audio over HDMI. Faded colors with dc=1 has been a longstanding issue for me. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[REGRESSION] drm/etnaviv: command buffer outside valid memory window
While updating my various systems for the TCP SACK issue, I notice that while most platforms are happy, the Cubox-i4 is not. During boot, we get: [0.00] cma: Reserved 256 MiB at 0x3000 ... [0.00] Kernel command line: console=ttymxc0,115200n8 console=tty1 video=mxcfb0:dev=hdmi root=/dev/nfs rw cma=256M ahci_imx.hotplug=1 splash resume=/dev/sda1 [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1790972K/2097152K available (8471K kernel code, 693K rwdata, 2844K rodata, 500K init, 8062K bss, 44036K reserved, 262144K cma-reserved, 1310720K highmem) ... [ 13.101098] etnaviv-gpu 13.gpu: command buffer outside valid memory window [ 13.171963] etnaviv-gpu 134000.gpu: command buffer outside valid memory window and shortly after the login prompt appears, the entire SoC appears to lock up - it becomes unresponsive on the network, or via serial console to sysrq requests. I suspect the GPU ends up scribbling over the CPU's vector page/kernel as a result of the above two etnaviv errors when Xorg attempts to start using the GPU. This used to work, so its a regression. -- 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110964] Documentation update about provided Open Vulkan implementation
https://bugs.freedesktop.org/show_bug.cgi?id=110964 Eric Engestrom changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Eric Engestrom --- We have no control over that docs website. Try to raise the issue or send an MR on their repo: https://gitlab.com/amdgpu/docs/amdgpu-install -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110965, which changed state. Bug 110965 Summary: Documentation update about not provided PX package https://bugs.freedesktop.org/show_bug.cgi?id=110965 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110965] Documentation update about not provided PX package
https://bugs.freedesktop.org/show_bug.cgi?id=110965 Eric Engestrom changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Eric Engestrom --- We have no control over that docs website. Try to raise the issue or send an MR on their repo: https://gitlab.com/amdgpu/docs/amdgpu-install -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110964, which changed state. Bug 110964 Summary: Documentation update about provided Open Vulkan implementation https://bugs.freedesktop.org/show_bug.cgi?id=110964 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 --- Comment #4 from Eric Engestrom --- OK, there are 4 issues left: 110965 & 110964 are about the docs on https://amdgpu-install.readthedocs.io/; a quick look at the repo shows only one member, Tim Writer (https://gitlab.com/amdgpu/docs/amdgpu-install/-/project_members). You should try to contact him about these, or maybe simply send him an MR with your updates. I'll close these two now. 110958 is about the docs on the AMD.com website, which we have no control over, but there are some AMD devs that read the bug tracker; maybe they'll see this bug and know how to update the docs. Lastly, 110966 is about the Vulkan SDK from LunarG; I don't know much about it other than the fact it is used on Windows to distribute the vulkan loader (the thing that manages the various vendors' vulkan drivers). As for the api version numbers, 1.1.x should be all compatible with one another, aside from missing features from newer releases, obviously. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110968, which changed state. Bug 110968 Summary: Allow ubuntu users to install on other ubuntu versions https://bugs.freedesktop.org/show_bug.cgi?id=110968 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110968] Allow ubuntu users to install on other ubuntu versions
https://bugs.freedesktop.org/show_bug.cgi?id=110968 Eric Engestrom changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Eric Engestrom --- Ubuntu packaging issue; this needs to be reported to Ubuntu instead. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110967, which changed state. Bug 110967 Summary: Naming packages with pro suffix depending if open or close source https://bugs.freedesktop.org/show_bug.cgi?id=110967 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110967] Naming packages with pro suffix depending if open or close source
https://bugs.freedesktop.org/show_bug.cgi?id=110967 Eric Engestrom changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Eric Engestrom --- Ubuntu packaging issue; this needs to be reported to Ubuntu instead. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110963, which changed state. Bug 110963 Summary: Wrong condition and wrong variable substitution in libgl1-amdgpu-mesa-dri in postinst script https://bugs.freedesktop.org/show_bug.cgi?id=110963 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110962] Wrong dependencies cause force dependency on amdgpu-dkms
https://bugs.freedesktop.org/show_bug.cgi?id=110962 Eric Engestrom changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Eric Engestrom --- Ubuntu packaging issue; this needs to be reported to Ubuntu instead. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110963] Wrong condition and wrong variable substitution in libgl1-amdgpu-mesa-dri in postinst script
https://bugs.freedesktop.org/show_bug.cgi?id=110963 Eric Engestrom changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Eric Engestrom --- Ubuntu packaging issue; this needs to be reported to Ubuntu instead. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110962, which changed state. Bug 110962 Summary: Wrong dependencies cause force dependency on amdgpu-dkms https://bugs.freedesktop.org/show_bug.cgi?id=110962 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110961, which changed state. Bug 110961 Summary: Are provoded libdrm packages completely open source? https://bugs.freedesktop.org/show_bug.cgi?id=110961 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110961] Are provoded libdrm packages completely open source?
https://bugs.freedesktop.org/show_bug.cgi?id=110961 Eric Engestrom changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Eric Engestrom --- Ubuntu packaging issue; this needs to be reported to Ubuntu instead. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110960, which changed state. Bug 110960 Summary: Non-existent alternative dependencies in some deb packages https://bugs.freedesktop.org/show_bug.cgi?id=110960 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110960] Non-existent alternative dependencies in some deb packages
https://bugs.freedesktop.org/show_bug.cgi?id=110960 Eric Engestrom changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Eric Engestrom --- Ubuntu packaging issue; this needs to be reported to Ubuntu instead. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110959, which changed state. Bug 110959 Summary: Broken link to Homepage of some packages https://bugs.freedesktop.org/show_bug.cgi?id=110959 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110959] Broken link to Homepage of some packages
https://bugs.freedesktop.org/show_bug.cgi?id=110959 Eric Engestrom changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Eric Engestrom --- Ubuntu packaging issue; this needs to be reported to Ubuntu instead. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110957] wsa-amdgpu package has empty copyright file
https://bugs.freedesktop.org/show_bug.cgi?id=110957 Eric Engestrom changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Eric Engestrom --- Ubuntu packaging issue; this needs to be reported to Ubuntu instead. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Bug 110956 depends on bug 110957, which changed state. Bug 110957 Summary: wsa-amdgpu package has empty copyright file https://bugs.freedesktop.org/show_bug.cgi?id=110957 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110958] Mentioning 32 bit OS support in Release page
https://bugs.freedesktop.org/show_bug.cgi?id=110958 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110963] Wrong condition and wrong variable substitution in libgl1-amdgpu-mesa-dri in postinst script
https://bugs.freedesktop.org/show_bug.cgi?id=110963 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110966] Documentation update about required lunar sdk
https://bugs.freedesktop.org/show_bug.cgi?id=110966 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110957] wsa-amdgpu package has empty copyright file
https://bugs.freedesktop.org/show_bug.cgi?id=110957 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110962] Wrong dependencies cause force dependency on amdgpu-dkms
https://bugs.freedesktop.org/show_bug.cgi?id=110962 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110967] Naming packages with pro suffix depending if open or close source
https://bugs.freedesktop.org/show_bug.cgi?id=110967 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110959] Broken link to Homepage of some packages
https://bugs.freedesktop.org/show_bug.cgi?id=110959 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110968] Allow ubuntu users to install on other ubuntu versions
https://bugs.freedesktop.org/show_bug.cgi?id=110968 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110965] Documentation update about not provided PX package
https://bugs.freedesktop.org/show_bug.cgi?id=110965 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110956] List of 19.20-812932 release mistakes
https://bugs.freedesktop.org/show_bug.cgi?id=110956 Eric Engestrom changed: What|Removed |Added Depends on||110957, 110958, 110959, ||110960, 110961, 110962, ||110963, 110964, 110965, ||110966, 110967, 110968 --- Comment #3 from Eric Engestrom --- I added the bugs you created in the dependency list for this one so that it tracks the overall progress. That said, from a quick overview those are all Ubuntu packaging issues, which means you need to talk to Ubuntu about these, we can't do anything about it. I'll close the ones that are clearly something the Ubuntu packager needs to do as INVALID; I hope you don't take it badly, this was just the wrong bug tracker ;) BTW, when possible you should try to make a proper Arch package instead of taking what someone built for Ubuntu and extracting it on Arch. There are things like file paths that change depending on the distro and might get built into the file, so your method might lead to spurious failures. Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110957 [Bug 110957] wsa-amdgpu package has empty copyright file https://bugs.freedesktop.org/show_bug.cgi?id=110958 [Bug 110958] Mentioning 32 bit OS support in Release page https://bugs.freedesktop.org/show_bug.cgi?id=110959 [Bug 110959] Broken link to Homepage of some packages https://bugs.freedesktop.org/show_bug.cgi?id=110960 [Bug 110960] Non-existent alternative dependencies in some deb packages https://bugs.freedesktop.org/show_bug.cgi?id=110961 [Bug 110961] Are provoded libdrm packages completely open source? https://bugs.freedesktop.org/show_bug.cgi?id=110962 [Bug 110962] Wrong dependencies cause force dependency on amdgpu-dkms https://bugs.freedesktop.org/show_bug.cgi?id=110963 [Bug 110963] Wrong condition and wrong variable substitution in libgl1-amdgpu-mesa-dri in postinst script https://bugs.freedesktop.org/show_bug.cgi?id=110964 [Bug 110964] Documentation update about provided Open Vulkan implementation https://bugs.freedesktop.org/show_bug.cgi?id=110965 [Bug 110965] Documentation update about not provided PX package https://bugs.freedesktop.org/show_bug.cgi?id=110966 [Bug 110966] Documentation update about required lunar sdk https://bugs.freedesktop.org/show_bug.cgi?id=110967 [Bug 110967] Naming packages with pro suffix depending if open or close source https://bugs.freedesktop.org/show_bug.cgi?id=110968 [Bug 110968] Allow ubuntu users to install on other ubuntu versions -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110964] Documentation update about provided Open Vulkan implementation
https://bugs.freedesktop.org/show_bug.cgi?id=110964 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110960] Non-existent alternative dependencies in some deb packages
https://bugs.freedesktop.org/show_bug.cgi?id=110960 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110961] Are provoded libdrm packages completely open source?
https://bugs.freedesktop.org/show_bug.cgi?id=110961 Eric Engestrom changed: What|Removed |Added Blocks||110956 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110956 [Bug 110956] List of 19.20-812932 release mistakes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/2] drm/vmwgfx: drop use of drmP.h
In two steps drop the use of drmP.h First patch remove drmP.h from header files and fixes fallout. Second patch remove drmP.h from the remaining files. While touching the list of include files divide them in blocks and sort include files within the blocks. Patches made on top of drm-misc-next, and checked that they apply to vmwgfx-fixes-5.2 in git://people.freedesktop.org/~thomash/linux Build tested with various configs with several architectures. Sam Sam Ravnborg (2): drm/vmwgfx: drop use of drmP.h in header files drm/vmwgfx: drop reminaing users of drmP.h drivers/gpu/drm/vmwgfx/ttm_lock.h | 2 +- drivers/gpu/drm/vmwgfx/ttm_object.h| 7 --- drivers/gpu/drm/vmwgfx/vmwgfx_binding.h| 3 ++- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 3 +++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 17 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 30 +- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 8 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 3 ++- drivers/gpu/drm/vmwgfx/vmwgfx_fence.h | 5 - drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 6 -- drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c| 4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_irq.c| 3 ++- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 10 +++--- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 6 -- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c| 11 +-- drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c| 6 ++ drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 5 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 6 -- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 9 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 3 ++- 23 files changed, 93 insertions(+), 58 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/2] drm/vmwgfx: drop use of drmP.h in header files
To facilitate removal of drmP.h in the .c files remove the use from header files first. Fix fallout in the other files. Sorted include files in blocks and sorted files within each block in alphabetical order. This revealed a dependency from an uapi header to a header located below drivers/gpu/drm/vmwgfx/. Added FIXME to remind someone to fix this. Signed-off-by: Sam Ravnborg Cc: VMware Graphics Cc: Thomas Hellstrom Cc: David Airlie Cc: Daniel Vetter --- drivers/gpu/drm/vmwgfx/ttm_lock.h | 2 +- drivers/gpu/drm/vmwgfx/ttm_object.h| 7 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_binding.h| 3 ++- drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 3 +++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 30 +++--- drivers/gpu/drm/vmwgfx/vmwgfx_fence.h | 5 +++- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 10 +--- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 6 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 6 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 9 --- drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 3 ++- 12 files changed, 59 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/ttm_lock.h b/drivers/gpu/drm/vmwgfx/ttm_lock.h index 0c3af9836863..886ab45d003f 100644 --- a/drivers/gpu/drm/vmwgfx/ttm_lock.h +++ b/drivers/gpu/drm/vmwgfx/ttm_lock.h @@ -49,8 +49,8 @@ #ifndef _TTM_LOCK_H_ #define _TTM_LOCK_H_ -#include #include +#include #include "ttm_object.h" diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.h b/drivers/gpu/drm/vmwgfx/ttm_object.h index 50d26c7ff42d..ede26df87c93 100644 --- a/drivers/gpu/drm/vmwgfx/ttm_object.h +++ b/drivers/gpu/drm/vmwgfx/ttm_object.h @@ -37,11 +37,12 @@ #ifndef _TTM_OBJECT_H_ #define _TTM_OBJECT_H_ -#include -#include +#include #include +#include #include -#include + +#include #include /** diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h index f6ab79d23923..cd9805c045cb 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h @@ -27,9 +27,10 @@ #ifndef _VMWGFX_BINDING_H_ #define _VMWGFX_BINDING_H_ -#include "device_include/svga3d_reg.h" #include +#include "device_include/svga3d_reg.h" + #define VMW_MAX_VIEW_BINDINGS 128 struct vmw_private; diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c index 56979e412ca8..065015d2a8f6 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c @@ -25,6 +25,9 @@ * **/ +#include +#include + #include #include "vmwgfx_drv.h" diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h index 366dcfc1f9bb..35874706ee0d 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h @@ -28,20 +28,32 @@ #ifndef _VMWGFX_DRV_H_ #define _VMWGFX_DRV_H_ -#include "vmwgfx_validation.h" -#include "vmwgfx_reg.h" -#include -#include -#include -#include #include +#include + +#include +#include +#include +#include +#include + #include #include #include -#include "vmwgfx_fence.h" -#include "ttm_object.h" + #include "ttm_lock.h" -#include +#include "ttm_object.h" + +#include "vmwgfx_fence.h" +#include "vmwgfx_reg.h" +#include "vmwgfx_validation.h" + +/* + * FIXME: vmwgfx_drm.h needs to be last due to dependencies. + * uapi headers should not depend on header files outside uapi/. + */ +#include + #define VMWGFX_DRIVER_NAME "vmwgfx" #define VMWGFX_DRIVER_DATE "20180704" diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.h b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.h index c9382933c2b9..50e9fdd7acf1 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.h @@ -32,8 +32,11 @@ #define VMW_FENCE_WAIT_TIMEOUT (5*HZ) -struct vmw_private; +struct drm_device; +struct drm_file; +struct drm_pending_event; +struct vmw_private; struct vmw_fence_manager; /** diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index b97bc8e5944b..da2b123c6807 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -25,12 +25,16 @@ * **/ -#include "vmwgfx_kms.h" -#include #include #include -#include #include +#include +#include +#include +#include +#include + +#include "vmwgfx_kms.h" /* Might need a hrtimer here? */ #define VMWGFX_PRESENT_RATE ((HZ / 60 > 0) ? HZ / 60 : 1) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h index 535b03599e55..3ee03227607c 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h @@ -28,9 +28,9 @@ #ifndef VMWGFX_KMS_H_ #define VMWGFX_KMS_H_ -#include #include #include +
[PATCH v1 2/2] drm/vmwgfx: drop reminaing users of drmP.h
Drop use of the deprecated drmP.h file from the
remaining files.
In several cases the drmP.h include could be removed without
furter fixes. Other files required a few header files to be added.
In all files divided includes files in blcoks and sort them.
Signed-off-by: Sam Ravnborg
Cc: VMware Graphics
Cc: Thomas Hellstrom
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 17 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 8
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c| 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 6 --
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 11 +--
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 6 ++
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 5 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 1 -
11 files changed, 34 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 5d5c2bce01f3..e6a776bfd8b9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -28,7 +28,6 @@
#include
-#include
#include "vmwgfx_drv.h"
#include "ttm_object.h"
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 89b8eb047583..0f07bcfa6d2f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -24,17 +24,22 @@
* USE OR OTHER DEALINGS IN THE SOFTWARE.
*
**/
-#include
+
#include
#include
+#include
-#include
-#include "vmwgfx_drv.h"
-#include "vmwgfx_binding.h"
-#include "ttm_object.h"
-#include
+#include
+#include
+#include
+#include
#include
#include
+#include
+
+#include "ttm_object.h"
+#include "vmwgfx_binding.h"
+#include "vmwgfx_drv.h"
#define VMWGFX_DRIVER_DESC "Linux drm driver for VMware graphics devices"
#define VMWGFX_CHIP_SVGAII 0
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index 972e8fda6d35..ea29953e0b08 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -26,14 +26,14 @@
*
**/
-#include
+#include
+
+#include
+#include
-#include
#include "vmwgfx_drv.h"
#include "vmwgfx_kms.h"
-#include
-
#define VMW_DIRTY_DELAY (HZ / 30)
struct vmw_fb_par {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 301260e23e52..434dfadb0e52 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -25,7 +25,8 @@
*
**/
-#include
+#include
+
#include "vmwgfx_drv.h"
#define VMW_FENCE_WRAP (1 << 31)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index ff3586cb6851..e5252ef3812f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -25,10 +25,12 @@
*
**/
-#include "vmwgfx_drv.h"
-#include
+#include
+
#include
+#include "vmwgfx_drv.h"
+
struct vmw_temp_set_context {
SVGA3dCmdHeader header;
SVGA3dCmdDXTempSetContext body;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
index ae7acc6f3dda..83c0d5a3e4fd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
@@ -25,10 +25,10 @@
*
**/
-#include "vmwgfx_drv.h"
-#include
#include
+#include "vmwgfx_drv.h"
+
#define VMW_PPN_SIZE (sizeof(unsigned long))
/* A future safe maximum remap size. */
#define VMW_PPN_PER_REMAP ((31 * 1024) / VMW_PPN_SIZE)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
index c3ad4478266b..75f3efee21a4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
@@ -25,7 +25,8 @@
*
**/
-#include
+#include
+
#include "vmwgfx_drv.h"
#define VMW_FENCE_WRAP (1 << 24)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 8b9270f31409..c9f634a4cc9e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -24,17 +24,16 @@
*
*/
-
-#include
-#include
-#include
#include
+#include
+#include
+#include
+
#include
-#include
+
#include "vmwgfx_drv.h"
#include "vmwgfx_msg.h"
-
#define MESSAGE_STATUS_SUCCESS 0x0001
#define MESSAGE_STATUS_DORECV 0x0002
#define MESSAGE_STATUS_CPT 0x0010
diff --git
[PATCH v1 0/2] drm: drop uapi dependencies from include/drm
include/drm/* shall have no or at least minimal dependencies to include/uapi/drm/*. Following two patches do a small effort to drop such dependencies. After these patches there are two users of uapi/drm/drm.h left in include/drm: drm_file.h: - needs drm_magic_t drm_magic_t is a simple typedef, a simple unsigned int would do the trick drm_legacy.h - needs drm_map_type and drm_map_flags. Seems legit. I did not spend time to analyze further dependencies. Patches are build tested. Sam Sam Ravnborg (2): drm: drop uapi dependency from drm_print.h drm: drop uapi dependency from drm_vblank.h include/drm/drm_print.h | 4 +--- include/drm/drm_vblank.h | 1 - 2 files changed, 1 insertion(+), 4 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/2] drm: drop uapi dependency from drm_vblank.h
drm_vblank.h included uapi/drm/drm.h. It turns out this include was not required - delete it. Note: uapi/drm/drm.h is included indirect via drm_file.h, but there are no dependencies in drm_vblank.h so the removal is legit. Signed-off-by: Sam Ravnborg Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter --- include/drm/drm_vblank.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h index e528bb2f659d..9fe4ba8bc622 100644 --- a/include/drm/drm_vblank.h +++ b/include/drm/drm_vblank.h @@ -30,7 +30,6 @@ #include #include -#include struct drm_device; struct drm_crtc; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/2] drm: drop uapi dependency from drm_print.h
drm_print.h used DRM_NAME - thus adding a dependency from include/drm/drm_print.h => uapi/drm/drm.h Hardcode the name "drm" to break this dependency. The idea is that there shall be a minimal dependency between include/drm/* and uapi/* Signed-off-by: Sam Ravnborg Suggested-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter --- include/drm/drm_print.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index a5d6f2f3e430..760d1bd0eaf1 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -32,8 +32,6 @@ #include #include -#include - /** * DOC: print * @@ -287,7 +285,7 @@ void drm_err(const char *format, ...); /* Macros to make printk easier */ #define _DRM_PRINTK(once, level, fmt, ...) \ - printk##once(KERN_##level "[" DRM_NAME "] " fmt, ##__VA_ARGS__) + printk##once(KERN_##level "[drm] " fmt, ##__VA_ARGS__) #define DRM_INFO(fmt, ...) \ _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] drm/exynos: drop use of drmP.h
Build tested using allyesconfig, allmodconfig for various architectures. v2: - add missing people to recipient list of mail - no change in actual patch v3: - fix build breakage (Inki Dae) - The testing I had done with allyesconfig, allmodconfig did not trigger a configuration where exynos_drm_g2d.c was built. v4: - added new patch so we get better build coverage of exynos driver (Krzysztof) A warning was triggered when building for sh - patch sent out to fix it in sh: https://lore.kernel.org/lkml/20190622114208.24427-1-...@ravnborg.org/ Sam Sam Ravnborg (2): drm/exynos: drop drmP.h usage drm/exynos: trigger build of all modules drivers/gpu/drm/exynos/Kconfig| 6 ++-- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++-- drivers/gpu/drm/exynos/exynos7_drm_decon.c| 8 -- drivers/gpu/drm/exynos/exynos_dp.c| 13 - drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dma.c | 6 ++-- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 +++--- drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 drivers/gpu/drm/exynos/exynos_drm_drv.h | 8 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 21 +++--- drivers/gpu/drm/exynos/exynos_drm_fb.c| 6 ++-- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 8 -- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 15 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 + drivers/gpu/drm/exynos/exynos_drm_g2d.c | 11 --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 +++-- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 13 + drivers/gpu/drm/exynos/exynos_drm_ipp.c | 3 +- drivers/gpu/drm/exynos/exynos_drm_mic.c | 22 +++--- drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +-- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 10 +++ drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 9 +++--- drivers/gpu/drm/exynos/exynos_hdmi.c | 41 +-- drivers/gpu/drm/exynos/exynos_mixer.c | 31 ++-- 25 files changed, 158 insertions(+), 139 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] drm/exynos: drop drmP.h usage
Drop use of the deprecated drmP.h file. Replace with forwards / externals as appropriate. While touching the list of include files divide them up in blocks and sort them. v3: - fix build errors in exynos_drm_g2d.c (Inki Dae) The exynos_drm_g2d.c file is not built in the standard configurations and was therefore missed. Signed-off-by: Sam Ravnborg Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: David Airlie Cc: Daniel Vetter Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: Jingoo Han --- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++- drivers/gpu/drm/exynos/exynos7_drm_decon.c| 8 ++-- drivers/gpu/drm/exynos/exynos_dp.c| 13 +++--- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dma.c | 6 ++- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 ++-- drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 +++--- drivers/gpu/drm/exynos/exynos_drm_drv.h | 8 +++- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 21 +- drivers/gpu/drm/exynos/exynos_drm_fb.c| 6 +-- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 7 ++-- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 15 +++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 11 +++-- drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 ++-- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 13 +++--- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 3 +- drivers/gpu/drm/exynos/exynos_drm_mic.c | 22 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 10 ++--- drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 +++--- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 9 ++-- drivers/gpu/drm/exynos/exynos_hdmi.c | 41 +-- drivers/gpu/drm/exynos/exynos_mixer.c | 31 +++--- 24 files changed, 154 insertions(+), 136 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c index 0650b619de24..2d5cbfda3ca7 100644 --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c @@ -7,7 +7,6 @@ * Hyungwon Hwang */ -#include #include #include #include @@ -15,11 +14,15 @@ #include #include #include +#include #include #include -#include "exynos_drm_drv.h" +#include +#include + #include "exynos_drm_crtc.h" +#include "exynos_drm_drv.h" #include "exynos_drm_fb.h" #include "exynos_drm_plane.h" #include "regs-decon5433.h" diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c index 13509ca8aa35..f0640950bd46 100644 --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c @@ -6,8 +6,6 @@ * Akshu Agarwal * Ajay Kumar */ -#include -#include #include #include @@ -21,10 +19,14 @@ #include #include +#include +#include +#include + #include "exynos_drm_crtc.h" -#include "exynos_drm_plane.h" #include "exynos_drm_drv.h" #include "exynos_drm_fb.h" +#include "exynos_drm_plane.h" #include "regs-decon7.h" /* diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c index c0653d007ca4..3a0f0ba8c63a 100644 --- a/drivers/gpu/drm/exynos/exynos_dp.c +++ b/drivers/gpu/drm/exynos/exynos_dp.c @@ -6,25 +6,24 @@ * Author: Jingoo Han */ -#include -#include -#include #include -#include #include +#include +#include +#include +#include #include #include #include #include -#include +#include #include #include #include #include +#include #include - -#include #include #include "exynos_drm_crtc.h" diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 98bec7418f01..77ce78986408 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -8,11 +8,11 @@ * Seung-Woo Kim */ -#include #include #include #include #include +#include #include "exynos_drm_crtc.h" #include "exynos_drm_drv.h" diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c b/drivers/gpu/drm/exynos/exynos_drm_dma.c index bef8bc3c8e00..9ebc02768847 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dma.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c @@ -4,11 +4,13 @@ // Author: Inki Dae // Author: Andrzej Hajda -#include -#include #include #include #include +#include + +#include +#include #include "exynos_drm_drv.h" diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c index 6ea92173db9f..87289db12868 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c @@ -10,14 +10,14 @@ * published by the Free Software Foundation. */ -#include +#include +#include + #include #include +#include
[PATCH v4 2/2] drm/exynos: trigger build of all modules
Add COMPILE_TEST dependency to force exynos driver to built for more than arm and to built modules that otherwise required other symbols to be de-selected. This will increase build coverage of the exynos driver thus allowing most trivial build errors to be detected/fixed early. This introduces one warning when built using sh: exynos7_drm_decon.c: In function ‘decon_remove’: exynos7_drm_decon.c:769:24: warning: unused variable ‘ctx’ struct decon_context *ctx = dev_get_drvdata(>dev); This is due to the definition of iounmap() in sh, and nothing that exynos driver can fix. Include fix of exynos build for alpha. Signed-off-by: Sam Ravnborg Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: David Airlie Cc: Daniel Vetter Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: Jingoo Han --- drivers/gpu/drm/exynos/Kconfig| 6 +++--- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 + 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index cbe58d307d1c..60ce4a8ad9e1 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_EXYNOS tristate "DRM Support for Samsung SoC EXYNOS Series" - depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || ARCH_MULTIPLATFORM) + depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || ARCH_MULTIPLATFORM || COMPILE_TEST) select DRM_KMS_HELPER select VIDEOMODE_HELPERS select SND_SOC_HDMI_CODEC if SND_SOC @@ -86,7 +86,7 @@ comment "Sub-drivers" config DRM_EXYNOS_G2D bool "G2D" - depends on VIDEO_SAMSUNG_S5P_G2D=n + depends on VIDEO_SAMSUNG_S5P_G2D=n || COMPILE_TEST select FRAME_VECTOR help Choose this option if you want to use Exynos G2D for DRM. @@ -114,7 +114,7 @@ config DRM_EXYNOS_SCALER config DRM_EXYNOS_GSC bool "GScaler" - depends on VIDEO_SAMSUNG_EXYNOS_GSC=n + depends on VIDEO_SAMSUNG_EXYNOS_GSC=n || COMPILE_TEST select DRM_EXYNOS_IPP help Choose this option if you want to use Exynos GSC for DRM. diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index aefcd624fe32..b0877b97291c 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -10,6 +10,7 @@ #include #include +#include #include #include -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS documentation for userspace
On Sat, Jun 22, 2019 at 11:42 AM Simon Ser wrote: > On Wednesday, June 19, 2019 10:53 PM, Daniel Vetter wrote: > > tldr; Yes, I just didn't get around to it yet. > > > > The rough plan is to actually document ioctls and properties and all > > that stuff in drm-uapi.rst, and then cross-link that with the > > driver-side documentation. > > I'm confused regarding drm-uapi.rst's role. Is it a document for kernel driver > writers to expand the uAPI, or is it a document for userspace? > > It's currently filled with references to internal kernel symbols > (drm_master_get, drm_ioctl_desc, drm_ioctl_permit and so on). Some chapters > seem > dedicated to kernel devs (e.g. "Testing and validation"). > > Is it really the right place for userspace devs to learn how to use KMS? There's more to drm than kms, but yeah I think currently that's the best starting point we have for documenting the uapi. We might also need to separate some of the more kernel-internal bits into other chapters, e.g. ioctl and master stuff is currently there because those are fairly important concept from a drm uapi pov. But maybe we should pull out the implementation details into some other place. Given that 0 of our ioctls and ioctl structures are currently documented, I'm not really worried about those issues just yet :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS documentation for userspace
On Wed, Jun 19, 2019 at 10:16 PM Jani Nikula wrote: > > On Wed, 19 Jun 2019, Daniel Vetter wrote: > > - figure out what to do with the libdrm manpages. Some stuff we really > > want to also document there. But geez nroff. Maybe we need to stuff > > libdrm into the kernel, dunno. > > How would people feel about converting libdrm man pages to rst, and > using rst2man in the build? We did that for igt man pages [1]. Looking > at the diff, I think it's plain to see how that could lower the bar for > contributing. And perhaps it would be easier to refactor and move > documentation around too. I think that'd be very nice. > I forget, I probably used pandoc or something to do the bulk of the igt > conversion, and added some manual polish on top. I'm not volunteering > for the libdrm man page conversion though. ;) Hm, maybe dig out the old tools you used and point Simon at them? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS documentation for userspace
On Wednesday, June 19, 2019 10:53 PM, Daniel Vetter wrote: > tldr; Yes, I just didn't get around to it yet. > > The rough plan is to actually document ioctls and properties and all > that stuff in drm-uapi.rst, and then cross-link that with the > driver-side documentation. I'm confused regarding drm-uapi.rst's role. Is it a document for kernel driver writers to expand the uAPI, or is it a document for userspace? It's currently filled with references to internal kernel symbols (drm_master_get, drm_ioctl_desc, drm_ioctl_permit and so on). Some chapters seem dedicated to kernel devs (e.g. "Testing and validation"). Is it really the right place for userspace devs to learn how to use KMS? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/18] drm/ttm: make ttm bo a gem bo subclass
Hi Thomas,
On Sat, Jun 22, 2019 at 12:52 AM Thomas Hellstrom wrote:
> On 6/21/19 5:57 PM, Daniel Vetter wrote:
> > On Fri, Jun 21, 2019 at 05:12:19PM +0200, Thomas Hellström (VMware) wrote:
> >>
> >> On 6/21/19 1:57 PM, Gerd Hoffmann wrote:
> >>
> >> Aargh. Please don't do this. Multiple reasons:
> >>
> >> 1) I think It's bad to dump all buffer object functionality we can possibly
> >> think of in a single struct and force that on all (well at least most)
> >> users. It's better to isolate functionality in structs, have utility
> >> functions for those and let the drivers derive their buffer objects from
> >> whatever functionality they actually need.
> >> 2) vmwgfx is not using gem and we don't want to carry that extra payload in
> >> the buffer object.
> >> 3) TTM historically hasn't been using the various drm layers except for
> >> later when common helpers have been used, (like the vma manager and the
> >> cache utilities). It's desirable to keep that layer distinction. (which is
> >> really what I'm saying in 1.)
> >>
> >> Now if more and more functionality that originated in TTM is moving into
> >> GEM
> >> we need to find a better way to do that without duplicating functionality.
> >> I
> >> suggest adding pointers in the TTM structs and defaulting those pointers to
> >> the member in the TTM struct. Optionally to to the member in the GEM
> >> struct.
> >> If we need to migrate those members out of the TTM struct, vmwgfx would
> >> have
> >> to provide them in its own buffer class.
> >>
> >> NAK from the vmwgfx side.
> > It's 59 DRIVER_GEM vs 1 which is not. I think the verdict is clear what
> > the reasonable thing to do is here, and this will allow us to
> > substantially improve code and concept sharing across drm drivers.
> >
> > 10 years ago it was indeed not clear whether everyone doing the same is a
> > bright idea, but that's no more. If you want I guess you can keep a
> > private copy of ttm in vmwgfx, but not sure that's really worth it
> > long-term.
> > -Daniel
>
> It's not a question about whether GEM or TTM, or even the number of
> drivers using one or the other. (GEM would actually be a good choice for
> the latter vmwgfx device versions). But this is going against all recent
> effort to make different parts of drm functionality recently self-contained.
>
> Just stop and think for a while what would happen if someone would
> suggest doing the opposite: making a gem object a derived class of a TTM
> object, arguing that a lot of GEM drivers are using TTM as a backend.
> There would probably be a lot of people claiming "we don't want to
> unnecesarily carry that stuff". That's because that would also be a poor
> design.
That case is a bit a different case. We have
- 5 ttm+gem drivers, recently refactored into vram helpers (but still
ttm underneath)
- 5 ttm+gem drivers, using ttm directly
- 1 ttm driver, no gem
- 48 other gem drivers with no vram support
- 1 gem driver which will gain vram support shortly, with or without
ttm still not clear
11:48 is not even close to 59:1 imo. And I think even if Thomas
Zimmermann and others get really busy porting old discrete fbdev
drivers to kms, that ratio won't change much since we're also gaining
new soc drm drivers at a steady rate.
Also I wouldn't mind if we e.g. stuff a struct list_head lru; into
drm_gem_buffer_object, that's probably useful for many cases (not the
pure display drivers, but they tend to have so few bo it really wont
matter even if we add a few kb of cruft).
> What I'm suggesting is, build that improved code and concept sharing around
>
> struct gem_ttm_object {
> struct gem_object;
> struct ttm_object;
> };
I guess technically this would work too. Bit more churn (maybe
substantially more, I haven't looked tbh) to roll this out for all the
ttm drivers using gem.
> And lets work toghether to eliminate what's duplicated.
How would you share the bo.resv pointer with the above design? With
embedding ttm can use the gem one, and we drop a bunch of code (and
for all the ttm+gem drivers, one pointer they don't need twice). With
the side-by-side, which is the design all gem+ttm drivers used the
past few years, we still need that duplication. Same for the vma node
thing, which is also duplicated. And that's just the things Gerd did
in this initial patch series. I think Christian König has some ideas
around ttm_bo_(un)reserve, and I just sent out a patch series to
streamline how we handle the reservation_object pointer for prime
import/export.
> The vmwgfx driver is doing what it does mostly because all buffer
> objects do not need to be user-space visible, and do not need to be
> mapped by user-space. And there are other types of objects that DO need
> to be user-space visible, and that do need to be shared by processes.
> Hence user-space visibility is something that should be abstracted and
> made available to those objects. Not lumped together with all other
> potential buffer object functionality.
I'd still go
Re: [PATCH v3 0/1] drm/exynos: drop use of drmP.h
Hi Krzysztof. > > Adding a COMPILE_TEST dependency will enable the build > > for the allyesconfig, allmodconfig. > > Thats worths to consider to avoid future mistakes. > > > Oh yes, that definitely makes sense (assuming it compiles on all > archs). Maybe you can send a follow up adding these? The driver is limited to ARM today. I could take a shot at fixing build erros on other archs and then let the full driver depend on COMPILE_TEST. I will give it a spin. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/1] drm/exynos: drop use of drmP.h
On Sat, 22 Jun 2019 at 09:31, Sam Ravnborg wrote: > > Hi Krzysztof. > > > > Build tested using allyesconfig, allmodconfig for various > > > architectures. > > > > Hi, > > > > Thanks for fixes. Just for the record, allyesconfig/allmodconfig are > > not a proper way for build test specific drivers. They are nice but > > since all dependencies are in, they might miss a lot. You should build > > mentioned platform (exynos_defconfig on ARMv7, defconfig on ARMv8) and > > multi configs (multi_v7 on ARMv7). Such rule is also valid for other > > drivers, not specific to Exynos. > > Thanks for the feedback. I have added exynos_defconfig, > multi_v7_defconfig to my growing list of configs that I try when doing > cross driver changes. > They include defconfig + allnoconfig for the supported archs too. > > None of these configs would have triggered a build of exynos_drm_g2d.c > so to do that some manual twaeks of the confg was necessary. > > Adding a COMPILE_TEST dependency will enable the build > for the allyesconfig, allmodconfig. > Thats worths to consider to avoid future mistakes. > > Sam > > Something like this: > > From 9b29b85f25f4cc485f36efb8d658766fa9a252d9 Mon Sep 17 00:00:00 2001 > From: Sam Ravnborg > Date: Sat, 22 Jun 2019 09:24:06 +0200 > Subject: [PATCH v1] drm/exynos: trigger build of all modules > > Add COMPILE_TEST dependency to a few options to trigger that the modules > get built using allyesconfig, allmodconfig. > This allows a non-exynos developer to catch build issues > in files that is usually not built. > > Signed-off-by: Sam Ravnborg > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: David Airlie > Cc: Daniel Vetter > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: Jingoo Han > --- > drivers/gpu/drm/exynos/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig > index cbe58d307d1c..eadea2daf1ab 100644 > --- a/drivers/gpu/drm/exynos/Kconfig > +++ b/drivers/gpu/drm/exynos/Kconfig > @@ -86,7 +86,7 @@ comment "Sub-drivers" > > config DRM_EXYNOS_G2D > bool "G2D" > - depends on VIDEO_SAMSUNG_S5P_G2D=n > + depends on VIDEO_SAMSUNG_S5P_G2D=n || COMPILE_TEST Oh yes, that definitely makes sense (assuming it compiles on all archs). Maybe you can send a follow up adding these? Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/1] drm/exynos: drop use of drmP.h
Hi Krzysztof. > > Build tested using allyesconfig, allmodconfig for various > > architectures. > > Hi, > > Thanks for fixes. Just for the record, allyesconfig/allmodconfig are > not a proper way for build test specific drivers. They are nice but > since all dependencies are in, they might miss a lot. You should build > mentioned platform (exynos_defconfig on ARMv7, defconfig on ARMv8) and > multi configs (multi_v7 on ARMv7). Such rule is also valid for other > drivers, not specific to Exynos. Thanks for the feedback. I have added exynos_defconfig, multi_v7_defconfig to my growing list of configs that I try when doing cross driver changes. They include defconfig + allnoconfig for the supported archs too. None of these configs would have triggered a build of exynos_drm_g2d.c so to do that some manual twaeks of the confg was necessary. Adding a COMPILE_TEST dependency will enable the build for the allyesconfig, allmodconfig. Thats worths to consider to avoid future mistakes. Sam Something like this: From 9b29b85f25f4cc485f36efb8d658766fa9a252d9 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg Date: Sat, 22 Jun 2019 09:24:06 +0200 Subject: [PATCH v1] drm/exynos: trigger build of all modules Add COMPILE_TEST dependency to a few options to trigger that the modules get built using allyesconfig, allmodconfig. This allows a non-exynos developer to catch build issues in files that is usually not built. Signed-off-by: Sam Ravnborg Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: David Airlie Cc: Daniel Vetter Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: Jingoo Han --- drivers/gpu/drm/exynos/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index cbe58d307d1c..eadea2daf1ab 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -86,7 +86,7 @@ comment "Sub-drivers" config DRM_EXYNOS_G2D bool "G2D" - depends on VIDEO_SAMSUNG_S5P_G2D=n + depends on VIDEO_SAMSUNG_S5P_G2D=n || COMPILE_TEST select FRAME_VECTOR help Choose this option if you want to use Exynos G2D for DRM. @@ -114,7 +114,7 @@ config DRM_EXYNOS_SCALER config DRM_EXYNOS_GSC bool "GScaler" - depends on VIDEO_SAMSUNG_EXYNOS_GSC=n + depends on VIDEO_SAMSUNG_EXYNOS_GSC=n || COMPILE_TEST select DRM_EXYNOS_IPP help Choose this option if you want to use Exynos GSC for DRM. -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next-navi10 323/469] htmldocs: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:217: warning: Function parameter or member 'soc_bounding_box' not described in 'amdgpu_dis
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next-navi10 head: e82deaaf0052ac2c79d5f600a953bd951a0b4351 commit: 8ebfb4406404b21eef5c79b48ff3b2eb122c [323/469] drm/amd/display: Read soc_bounding_box from gpu_info (v2) reproduce: make htmldocs If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/generic-radix-tree.h:1: warning: no structured comments found lib/sort.c:59: warning: Excess function parameter 'size' description in 'swap_words_32' lib/sort.c:83: warning: Excess function parameter 'size' description in 'swap_words_64' lib/sort.c:110: warning: Excess function parameter 'size' description in 'swap_bytes' block/genhd.c:540: warning: Function parameter or member 'devt' not described in 'blk_invalidate_devt' kernel/rcu/tree_plugin.h:1: warning: no structured comments found include/net/cfg80211.h:1074: warning: Function parameter or member 'txpwr' not described in 'station_parameters' include/net/mac80211.h:4037: warning: Function parameter or member 'sta_set_txpwr' not described in 'ieee80211_ops' include/net/mac80211.h:2004: warning: Function parameter or member 'txpwr' not described in 'ieee80211_sta' kernel/rcu/tree_plugin.h:1: warning: no structured comments found include/linux/firmware/intel/stratix10-svc-client.h:1: warning: no structured comments found Error: Cannot open file drivers/counter/generic-counter.c Error: Cannot open file drivers/counter/generic-counter.c WARNING: kernel-doc 'scripts/kernel-doc -rst -enable-lineno -export drivers/counter/generic-counter.c' failed with return code 2 include/linux/gpio/driver.h:374: warning: Function parameter or member 'init_valid_mask' not described in 'gpio_chip' include/linux/i2c.h:343: warning: Function parameter or member 'init_irq' not described in 'i2c_client' include/linux/iio/hw-consumer.h:1: warning: no structured comments found drivers/base/node.c:78: warning: Function parameter or member 'hmem_attrs' not described in 'node_access_nodes' drivers/base/node.c:690: warning: Function parameter or member 'mem_nid' not described in 'register_memory_node_under_compute_node' drivers/base/node.c:690: warning: Function parameter or member 'cpu_nid' not described in 'register_memory_node_under_compute_node' drivers/base/node.c:690: warning: Excess function parameter 'mem_node' description in 'register_memory_node_under_compute_node' drivers/base/node.c:690: warning: Excess function parameter 'cpu_node' description in 'register_memory_node_under_compute_node' include/linux/input/sparse-keymap.h:46: warning: Function parameter or member 'sw' not described in 'key_entry' include/linux/regulator/machine.h:199: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:228: warning: Function parameter or member 'resume' not described in 'regulator_ops' drivers/slimbus/stream.c:1: warning: no structured comments found include/linux/spi/spi.h:188: warning: Function parameter or member 'driver_override' not described in 'spi_device' drivers/target/target_core_device.c:1: warning: no structured comments found drivers/usb/typec/bus.c:1: warning: no structured comments found drivers/usb/typec/class.c:1: warning: no structured comments found include/linux/w1.h:281: warning: Function parameter or member 'of_match_table' not described in 'w1_family' fs/direct-io.c:257: warning: Excess function parameter 'offset' description in 'dio_complete' fs/file_table.c:1: warning: no structured comments found fs/libfs.c:479: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:646: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:646: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:646: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:179: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_read_lock' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:347: warning: cannot understand function prototype: 'struct amdgpu_vm_pt_cursor ' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:348: warning: cannot understand function prototype: 'struct amdgpu_vm_pt_cursor ' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:494: warning: Function parameter or member 'start' not described in 'amdgpu_vm_pt_first_dfs' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'adev' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or
