Re: [PATCH 2/2] drm/amd: Re-create firmware framebuffer on failure to probe

[Ernst Sjöstrand]

What about a system with multiple GPUs?
Hybrid graphics?
Headless systems?

Regards
//Ernst

Den tors 22 dec. 2022 kl 19:30 skrev Mario Limonciello <
mario.limoncie...@amd.com>:

> If the probe sequence fails then the user is stuck with a frozen
> screen and can only really recover via SSH or by rebooting and
> applying nomodeset to the kernel command line.
>
> This is particularly problematic as newer GPUs are introduced because
> distributions may take some time to land newer GPU firmware.
>
> So when probe fails, re-create the system framebuffer so that the
> user at least has basic graphics support.
>
> Signed-off-by: Mario Limonciello 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index bf2d50c8c92a..8961c62ab29b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "amdgpu.h"
>  #include "amdgpu_irq.h"
> @@ -2187,6 +2188,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
>
>  err_pci:
> pci_disable_device(pdev);
> +   sysfb_enable();
> return ret;
>  }
>
> --
> 2.34.1
>
>

Re: [PATCH] drm/radeon: Add build directory to include path

[Ernst Sjöstrand]

Den sön 19 juni 2022 kl 00:20 skrev Masahiro Yamada :

> On Wed, Jun 15, 2022 at 5:35 PM Michel Dänzer
>  wrote:
> >
> > On 2022-04-14 18:57, Michel Dänzer wrote:
> > > On 2022-04-14 17:04, Masahiro Yamada wrote:
> > >> On Thu, Apr 14, 2022 at 10:50 PM Michel Dänzer
> > >>  wrote:
> > >>> On 2022-04-14 15:34, Alex Deucher wrote:
> >  On Thu, Apr 14, 2022 at 4:44 AM Christian König
> >   wrote:
> > > Am 14.04.22 um 09:37 schrieb Michel Dänzer:
> > >>
> > >>   make -C build-amd64 M=drivers/gpu/drm
> > >>
> > >>
> > >> Maybe
> > >>
> > >> make  O=build-arm64   drivers/gpu/drm/
> > >>
> > >> is the way you were searching for.
> > >>
> > >> It builds only drivers/gpu/drm/
> > >> in the separate directory.
> > >
> > > Indeed, that works.
> >
> > I've come to realize that this doesn't produce the actual *.ko modules
> though. Is there a trick for building the modules, but only under
> drivers/gpu/drm/ ?
> >
> >
> > --
> > Earthling Michel Dänzer|  https://redhat.com
> > Libre software enthusiast  | Mesa and Xwayland developer
>
>
> No.
> There is no way to build *.ko
> only under a specific directory.
>

Doesn't "make modules M=drivers/gpu/drm/" do that?

Re: [bug] Radeon 3900XT not switch to graphic mode on kernel 5.10

[Ernst Sjöstrand]

-2 means no such file or directory. Perhaps you need to rebuild your
ramdisk manually for some reason.

Regards
//Ernst

Den sön 27 dec. 2020 kl 17:58 skrev Mikhail Gavrilov <
mikhail.v.gavri...@gmail.com>:

> On Sun, 27 Dec 2020 at 21:39, Mikhail Gavrilov
>  wrote:
> > I suppose the root of cause my problem here:
> >
> > [3.961326] amdgpu :0b:00.0: Direct firmware load for
> > amdgpu/sienna_cichlid_sos.bin failed with error -2
> > [3.961359] amdgpu :0b:00.0: amdgpu: failed to init sos firmware
> > [3.961433] [drm:psp_sw_init [amdgpu]] *ERROR* Failed to load psp
> firmware!
> > [3.961529] [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* sw_init
> > of IP block  failed -2
> > [3.961549] amdgpu :0b:00.0: amdgpu: amdgpu_device_ip_init failed
> > [3.961569] amdgpu :0b:00.0: amdgpu: Fatal error during GPU init
> > [3.961911] amdgpu: probe of :0b:00.0 failed with error -2
> >
>
> # dnf provides */sienna_cichlid_sos.bin
> Last metadata expiration check: 3:01:27 ago on Sun 27 Dec 2020 06:53:25 PM
> +05.
> linux-firmware-20201218-116.fc34.noarch : Firmware files used by the
> Linux kernel
> Repo: @System
> Matched from:
> Filename: /usr/lib/firmware/amdgpu/sienna_cichlid_sos.bin
>
> linux-firmware-20201218-116.fc34.noarch : Firmware files used by the
> Linux kernel
> Repo: rawhide
> Matched from:
> Filename: /usr/lib/firmware/amdgpu/sienna_cichlid_sos.bin
>
> # dnf install linux-firmware-20201218-116.fc34.noarch
> Last metadata expiration check: 3:02:11 ago on Sun 27 Dec 2020 06:53:25 PM
> +05.
> Package linux-firmware-20201218-116.fc34.noarch is already installed.
> Dependencies resolved.
> Nothing to do.
> Complete!
>
> Looks like firmware is present. So I didn't understand why the kernel
> cannot read firmware.
>
> --
> Best Regards,
> Mike Gavrilov.
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu/drm/radeon: fix spellint typo in comments

[Ernst Sjöstrand]

There is a typo in your patch subject. ;-)

Regards
//Ernst

Den tis 22 sep. 2020 kl 15:11 skrev Wang Qing :

> Modify the comment typo: "definately" -> "definitely".
>
> Signed-off-by: Wang Qing 
> ---
>  drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index f60fae0..3d6e2cd
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -188,7 +188,7 @@ struct radeon_fence *radeon_vm_grab_id(struct
> radeon_device *rdev,
> vm_id->last_id_use == rdev->vm_manager.active[vm_id->id])
> return NULL;
>
> -   /* we definately need to flush */
> +   /* we definitely need to flush */
> vm_id->pd_gpu_addr = ~0ll;
>
> /* skip over VMID 0, since it is the system VM */
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/11] amd/display: Add GFX9+ modifier support.

[Ernst Sjöstrand]

Den fre 4 sep. 2020 kl 18:07 skrev Bas Nieuwenhuizen <
b...@basnieuwenhuizen.nl>:

> This adds modifier support to radeonsi.
>

Wouldn't it be more correct to say that this adds modifier support to
amdgpu (and enables it to work with radeonsi OpenGL)
or something like that?

//E


> It has been tested on
>
> - VEGA10, RAVEN, NAVI14
> - weston, sway, X with xf86-video-amdgpu (i.e. legacy path still works)
>
> and includes some basic testing of the layout code.
>
> The main goal is to keep it somewhat simple and regression free, so
> on the display side this series only exposes what the current GPU
> can render to. While we could expose more I think that is more
> suitable for follow-up work as the benefit would be minimal and
> there are some more design discussion there to discuss that are
> orthogonal from the initial implementation.
>
> Similarly this series only exposes 32-bpp displayable DCC in the cases
> that radeonsi would use it and any extra capabilities here should be
> future work.
>
> I believe these are by far the most complicated modifiers we've seen
> up till now, mostly related to
>
> - GPU identification for cases where it matters wrt tiling.
> - Every generation having tiling layout changes
> - Compression settings.
>
> I believe the complexity is necessary as every layout should be different
> and all layouts should be the best in some situation (though not all
> combinations of GPU parameters will actually have an existing GPU).
>
> That said, on the render side the number of modifiers actually listed for
> a given GPU is ~10, and in the current implementation that is the same
> for the display side. (we could expose more actually differing layouts
> on the display side for cross-GPU compatibility, but I consider that
> out of scope for this initial work).
>
> This series can be found on
> https://github.com/BNieuwenhuizen/linux/tree/modifiers
>
> An userspace implementation in radeonsi can be found on
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6176
>
> v2:
>
> Per suggestion from Daniel Vetter I added logic to get the tiling_flags at
> addfb2 time and convert them into modifiers for GFX9+.  Furthermore, the
> DCC
> constant econding modifers only get exposed on RAVEN2 and newer.
>
> Bas Nieuwenhuizen (11):
>   drm/amd/display: Do not silently accept DCC for multiplane formats.
>   drm/amd: Init modifier field of helper fb.
>   drm/amd/display: Honor the offset for plane 0.
>   drm/fourcc:  Add AMD DRM modifiers.
>   drm/amd/display: Store tiling_flags in the framebuffer.
>   drm/amd/display: Convert tiling_flags to modifiers.
>   drm/amd/display: Refactor surface tiling setup.
>   drm/amd/display: Set DC options from modifiers.
>   drm/amd/display: Add formats for DCC with 2/3 planes.
>   drm/amd/display: Expose modifiers.
>   drm/amd/display: Clean up GFX9 tiling_flags path.
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 169 +++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |   3 +
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 754 ++
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   2 -
>  include/uapi/drm/drm_fourcc.h | 115 +++
>  6 files changed, 880 insertions(+), 165 deletions(-)
>
> --
> 2.28.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC for a render API to support adaptive sync and VRR

[Ernst Sjöstrand]

It would be really nice to have support for the automatic
extension-less fullscreen game scenario. Maybe you don't have to solve
everything in the first implementation...
So a friendly ping here!

Regards
//Ernst

Den tis 24 apr. 2018 kl 23:58 skrev Daniel Vetter :
>
> On Tue, Apr 24, 2018 at 4:28 PM, Harry Wentland  
> wrote:
> >
> >
> > On 2018-04-24 08:09 AM, Daniel Vetter wrote:
> >> On Mon, Apr 23, 2018 at 02:19:44PM -0700, Manasi Navare wrote:
> >>> On Mon, Apr 23, 2018 at 10:40:06AM -0400, Harry Wentland wrote:
>  On 2018-04-20 04:32 PM, Manasi Navare wrote:
> > On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote:
> >> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard  
> >> wrote:
> >>> Michel Dänzer  writes:
>  Time-based presentation seems to be the right approach for preventing
>  micro-stutter in games as well, Croteam developers have been 
>  researching
>  this.
> >>>
> >>> Both the Vulkan GOOGLE_display_timing extension and X11 Present
> >>> extension offer the ability to specify the desired display time in
> >>> seconds.
> >>>
> >>> Similarly, I'd suggest that the min/max display refresh rate values be
> >>> advertised as time between frames rather than frames per second.
> >
> > So there is a global min and max refresh rate as advertised by the 
> > monitor
> > range descriptor. That I guess can be exposed as a global range in 
> > terms of
> > min and max time between frames as a global property of the connector.
> >
> > We dont need the per mode min and max refresh rate to be exposed right?
> 
>  If I understand VRR right, with CinemaVRR acceptable refresh rates might 
>  fall outside the range advertised by the monitor. Would we
>   1) advertise 24/1.001 as a lower bound,
>   2) expect media apps to use the lower bound simply for informational 
>  purposes,
>   3) or simply not support CinemaVRR?
> 
>  (1) has the added caveat that not all reported rates would be supported.
> 
>  Alternatively a bit could indicate that CinemaVRR is support, but I'm 
>  not sure if user mode would need all these details.
> 
>  Harry
> >>>
> >>> Are there special CinemaVRR suported monitors? In that case we need to 
> >>> understand how those monitors
> >>> advertise the monitor range and if they have a bit in EDID that indicate 
> >>> they are CinemaVRR capable
> >>> as opposed to just the Adaptive Sync/VRR.
> >>> Harry, if you have one of those monitors, could you send the EDID dump 
> >>> for that?
> >>
> >> As long as the any multiple of the 24/1.001 refresh rate is within the
> >> officially supported refresh range rate this should work out. Maybe we'll
> >> end up uploading 2x (to run at ~48Hz), maybe the kernel only uploads at
> >> 24Hz. But should all be fine.
> >>
> >
> > Would kernel driver upload 48Hz when UMD asks for 24Hz or would UMD be 
> > expected to submit double frames?
> >
> > If kernel driver supports frame doubling (like our DC driver) we would 
> > probably report half of monitor-reported min-refresh (or rather double of 
> > monitor-reported max frame time).
>
> Your driver (amdgpu) already supports frame doubling, except only for
> vblank seqno instead of timestamps. Whether VRR can get down to 24Hz
> or not is totally irrelevant from userspace's point of view. By
> default the kernel is expected to keep display the current frame for
> as long as userspace gives it a new one. There's no expectation that
> userspace provides a new buffer for every vblank (whether that's a
> fixed or variable refresh rate doesn't matter).
> -Daniel
>
> >
> > Harry
> >
> >> Ofc if we have CinemaVRR screens which don't fit this, then maybe we need
> >> to figure out something ...
> >> -Daniel
> >>
> >>>
> >>> Manasi
> >>>
> 
> >
> >>>
> >>> I'd also encourage using a single unit for all of these values,
> >>> preferably nanoseconds. Absolute times should all be referenced to
> >>> CLOCK_MONOTONIC.
> >>
> >> +1 on everything Keith said. I got somehow dragged in khr vk
> >> discussions around preventing micro-stuttering, and consensus seems to
> >> be that timestamps for scheduling frames is the way to go, most likely
> >> absolute ones (not everything is running Linux unfortunately, so can't
> >> go outright and claim it's guaranteed to be CLOCK_MONOTONIC).
> >> -Daniel
> >
> > And yes I also got consensus from Mesa and media folks about using the
> > absolute timestamp for scheduling the frames and then the driver will
> > modify the vblank logic to "present no earlier than the timestamp"
> >
> > Manasi
> >
> >> --
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >> ___
> >> dri-devel mailing list
> >> 

Re: [PATCH 1/2] drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()

[Ernst Sjöstrand]

Can't find these anywhere yet, errors still there.

https://patchwork.freedesktop.org/series/31220/

Regards
//Ernst

2017-09-30 10:25 GMT+02:00 Christian König :
> Am 30.09.2017 um 10:13 schrieb Dan Carpenter:
>>
>> We shifted some code around in commit 9cca0b8e5df0 ("drm/amdgpu: move
>> amdgpu_cs_sysvm_access_required into find_mapping") and now my static
>> checker complains that "r" might not be initialized at the end of the
>> function.  I've reviewed the code, and that seems possible, but it's
>> also possible I may have missed something.
>>
>> Signed-off-by: Dan Carpenter 
>
>
> Good catches, Reviewed-by: Christian König  for
> both patches.
>
>
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> index b46280c1279f..2918de2f39ec 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> @@ -648,7 +648,7 @@ int amdgpu_vce_ring_parse_cs(struct amdgpu_cs_parser
>> *p, uint32_t ib_idx)
>> uint32_t allocated = 0;
>> uint32_t tmp, handle = 0;
>> uint32_t *size = 
>> -   int i, r, idx = 0;
>> +   int i, r = 0, idx = 0;
>> p->job->vm = NULL;
>> ib->gpu_addr = amdgpu_sa_bo_gpu_addr(ib->sa_bo);
>
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Testing dc-drm-next-atomic-wip

[Ernst Sjöstrand]

Hi,

this is more feedback about how the code works and runs rather than
what you're really looking for, so I thought I'd start a new thread.
:-)

I get the following error when compiling and (obviously) forgetting to
enable the new DC option.
I see the option will be removed, so maybe that doesn't matter?

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function ‘amdgpu_device_init’:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1956:6: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  adev->dm_state = kzalloc(sizeof(*adev->dm_state), GFP_KERNEL);
  ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1956:39: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  adev->dm_state = kzalloc(sizeof(*adev->dm_state), GFP_KERNEL);
   ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1957:10: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  if (adev->dm_state == NULL)
  ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1959:6: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  adev->dm_state->dev = adev;
  ^~

Btw, perhaps you should add a dc-wip-something tag under versions in bugzilla?

Regards
//Ernst


2017-05-03 16:13 GMT+02:00 Harry Wentland :
> Hi all,
>
> Over the last few months we (mostly Andrey and myself) have taken and
> addressed some of the feedback received from December's DC RFC. A lot of our
> work so far centers around atomic. We were able to take a whole bunch of the
> areas where we rolled our own solution and use DRM atomic helpers instead.
>
> You can find our most recent drm-next based tree at
> https://cgit.freedesktop.org/~hwentland/linux/log/?h=dc-drm-next-atomic-wip
>
> An outline of the changes with commit hashes from that tree are listed
> below. They aren't necessarily in order but are grouped by functionality.
>
> I would like to solicit input on the changes and the current state of
> amd/display in general.
>
> I'm on IRC every weekday from 9-5 eastern time, sometimes at other hours.
> Feel free to ask questions, discuss, leave comments. Let me know if there's
> anything else I can do to facilitate review.
>
> We know there's more work to be done but would much rather prioritize that
> work based on community feedback than merely our own impressions.
>
> We haven't finished plumbing drm types to the dc types yet, and there are
> still a bunch of other things in progress.  We are not looking to re-hash
> the previous discussion, but rather we'd like some feedback on our work so
> far.
>
> The list of changes (trimmed commit tags):
>
> == Use common helpers for pageflip ==
> 144da239b047 Use pflip prepare and submit parts (v2)
> ff7ac264a9a1 Fix page flip after daniel's acquire_ctx change
>
>
> == implement atomic_get_properties ==
> cf4a84df7189 Fallback on legacy properties in atomic_get_properties
> 01f96706b6ca get_atomic_property missing for drm_connector_funcs
>
>
> == Use common helpers for gamma ==
> 3f547d7098de Use atomic helpers for gamma
>
>
> == Use atomic helpers for commit ==
> 41831f55bd58 Refactor atomic commit implementation. (v2)
> 6c67dd3c5cd5 Refactor headless to use atomic commit.
> eb22ef1ecb16 Remove page_fleep_needed function.
>
>
> == Use atomic helpers for S3 ==
> 5a6ae6f76249 Switch to DRM helpers in s3.
>
>
> == Simmplify mapping between DRM and DC objects ==
> 84a3ee023b9b Remove get_connector_for_link.
> 6d8978a98b40 Remove get_connector_for_sink.
>
>
> == Use DRM EDID read instead of DC ==
> 566969dacfad Fix i2c write flag.
> 527c3699ff3c Refactor edid read.
> 5ac51023d275 Fix missing irq refactor causing potential i2c race
>
>
> == Save DC validate_ctx in atomic_check and use in commit ==
> 8c194d8e4ee9 pull commit_surfaces out of atomic_commit into helper function
> 27eef98b38c8 Return context from validate_context
> ca3ee10e915b Add DM global atomic state
> 8ba1ca856532 Hook dm private state into atomic_check
> 10160455ac6d Add correct retain/release for objs in dm_atomic_state
> 0f1b2e2aecbb Commit validation set from state
> 258e6a91fc61 Add validate_context to atomic_state
> 64f569b5df20 Use validate_context from atomic_check in commit
>
>
> == Start multi-plane implementation ==
> 601ff4e70b7c decouple per-crtc-plane model
> a0b859a0b114 Fix cleanup in amdgpu_dm_initialize_drm_device
> ee02010d7a82 update plane functionalities
> 3b7345fd1abb Allow planes on all crtcs
> d9cf37462156 initialize YUV plane capabilities
> 248f06b2613e Universal cursor plane hook-up.
>
>
> == Minor cleanups ==
> d99bf02cb8fc Rename atomic_commit parameter.
> f15fb9726502 Use amdgpu mode funcs statically
> d3e37fa70643 Remove unused define from amdgpu_dm_types
> 80a38ad58125 Add lock around updating freesync property
> 8c7f16853824 Use new drm_dp_find_vcpi_slots to compute slots
>
> Regards,
> Harry
> ___
> amd-gfx 

[PATCH] drm: disable deep color when EDID violates spec

[Ernst Sjöstrand]

I kindof assume DP is the default connection these days and with Freesync
you use
DP or course, but this question was specifically for HDMI.
I guess this patch doesn't affect deep color over DP?

Anyway, only 17 of those monitors have FreeSync but almost all have DP, so
perhaps they only support
10 bpc when connected with DP?

Regards
//Ernst

2017-01-10 20:54 GMT+01:00 Alex Deucher :

> On Tue, Jan 10, 2017 at 12:46 PM, Ville Syrjälä
>  wrote:
> > On Tue, Jan 10, 2017 at 12:27:45PM -0500, Alex Deucher wrote:
> >> On Tue, Jan 10, 2017 at 6:33 AM, Ernst Sjöstrand 
> wrote:
> >> > Isn't 10bpc very common among monitors, and 12bpc very rare? Or maybe
> I'm
> >> > confusing the transport layer with the presentation capabilities...?
> >> > Here are 201 monitors that claim 10bpc:
> >> > http://pricespy.co.uk/category.php?l=s300859434=eg_401#prodlista
> >> >
> >>
> >> FWIW, I've almost never seen a monitor that supports 12 bpc, but I've
> >> see quite a few 10 bpc monitors.
> >
> > I've seen plenty of monitors that do 10bpc over DP, but I've never seen
> > anything that does 10bpc over HDMI. 12bpc over HDMI is pretty common
> > in "proper" TVs in my experience.
> >
> >> I can talk to our display team to
> >> see what other OSes do.
> >
> > Thanks. That should give us some idea if anyone ever tried 10bpc
> > over HDMI on these things.
>
> We apparently see this pretty commonly, especially with freesync
> monitors, and we support it.  It seems to be pretty prevalent because
> you can support a higher refresh rate with a lower bpc.
>
> Alex
>
> >
> >>
> >> Alex
> >>
> >> > Regards
> >> > //Ernst
> >> >
> >> > 2017-01-10 11:52 GMT+01:00 Ville Syrjälä <
> ville.syrjala at linux.intel.com>:
> >> >>
> >> >> On Thu, Jan 05, 2017 at 05:45:23PM -0600, Nicholas Sielicki wrote:
> >> >> > As per the HDMI 1.3 and 1.4 spec, "deep color modes" are color
> depths
> >> >> > greater than 24 bits per pixel. The spec explicitly states, "All
> Deep
> >> >> > Color modes are optional though if an HDMI Source or Sink supports
> any
> >> >> > Deep Color mode, it shall support 36-bit mode." (6.2.4 Color Depth
> >> >> > Requirements).
> >> >> >
> >> >> > I came across a monitor (Acer X233H) that supplies an illegal EDID
> where
> >> >> > DC_30bit is set and DC_36bit is not set. The end result is badly
> garbled
> >> >> > output because the driver is sending 36BPP when the monitor can't
> handle
> >> >> > it.
> >> >> >
> >> >> > Much of the intel hardware is incapable of operating at any
> >> >> > bit-per-component setting outside of 8 or 12, and the spec seems to
> >> >> > imply that if any deep color support is found, then it is a safe
> >> >> > assumption to operate at 12.
> >> >> >
> >> >> > This patch ensures that the EDID is within the spec (specifically,
> that
> >> >> > DC_36bit is set) before committing to going forward with any deep
> >> >> > colors.  There was already a check for this EDID inconsistency,
> but it
> >> >> > resulted only in a warning and did not fall-back to safer settings.
> >> >> >
> >> >> > CC: Ville Syrjälä 
> >> >> > Signed-off-by: Nicholas Sielicki 
> >> >> > ---
> >> >> >  drivers/gpu/drm/drm_edid.c | 35 +++---
> -
> >> >> >  1 file changed, 23 insertions(+), 12 deletions(-)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/drm_edid.c
> b/drivers/gpu/drm/drm_edid.c
> >> >> > index 336be31ff3de..42ce3f54d2dc 100644
> >> >> > --- a/drivers/gpu/drm/drm_edid.c
> >> >> > +++ b/drivers/gpu/drm/drm_edid.c
> >> >> > @@ -3772,30 +3772,34 @@ static void
> >> >> > drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> >> >> >  {
> >> >> >   struct drm_display_info *info = >display_info;
> >> >> >   unsigned int dc_bpc = 0;
> >> >> > + u8 modes = 0;
> >> >> >
> >> >> >   /* HDMI supports at least 8 bpc */
> >> >> >   info->bpc = 8;
> >> >> >
> >> >> > + /* Ensure all DC modes are unset if we return early */
> >> >> > + info->edid_hdmi_dc_modes = 0;
> >> >>
> >> >> Clearing this in drm_add_display_info() should be sufficient since
> >> >> this guy doesn't get called from anywhere else. So this part could
> >> >> be droppped.
> >> >>
> >> >> Otherwise this feels like a decent way to handle the problem. We
> >> >> could of course try to use the 10bpc (or whatever) deep color modes
> >> >> the sink claims to support, but given that the people designing the
> >> >> thing didn't bother reading the spec, it seems safer to just disable
> >> >> deep color support entirely.
> >> >>
> >> >> Reviewed-by: Ville Syrjälä 
> >> >>
> >> >> > +
> >> >> >   if (cea_db_payload_len(hdmi) < 6)
> >> >> >   return;
> >> >> >
> >> >> >   if (hdmi[6] & DRM_EDID_HDMI_DC_30) {
> >> >> >   dc_bpc = 10;
> >> >> > - info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_30;
> >> >> > + modes |= DRM_EDID_HDMI_DC_30;
> >> >> >   DRM_DEBUG("%s: HDMI sink does deep color 30.\n",
> >> >> > 

[PATCH] drm: disable deep color when EDID violates spec

[Ernst Sjöstrand]

Isn't 10bpc very common among monitors, and 12bpc very rare? Or maybe I'm
confusing the transport layer with the presentation capabilities...?
Here are 201 monitors that claim 10bpc:
http://pricespy.co.uk/category.php?l=s300859434=eg_401#prodlista

Regards
//Ernst

2017-01-10 11:52 GMT+01:00 Ville Syrjälä :

> On Thu, Jan 05, 2017 at 05:45:23PM -0600, Nicholas Sielicki wrote:
> > As per the HDMI 1.3 and 1.4 spec, "deep color modes" are color depths
> > greater than 24 bits per pixel. The spec explicitly states, "All Deep
> > Color modes are optional though if an HDMI Source or Sink supports any
> > Deep Color mode, it shall support 36-bit mode." (6.2.4 Color Depth
> > Requirements).
> >
> > I came across a monitor (Acer X233H) that supplies an illegal EDID where
> > DC_30bit is set and DC_36bit is not set. The end result is badly garbled
> > output because the driver is sending 36BPP when the monitor can't handle
> > it.
> >
> > Much of the intel hardware is incapable of operating at any
> > bit-per-component setting outside of 8 or 12, and the spec seems to
> > imply that if any deep color support is found, then it is a safe
> > assumption to operate at 12.
> >
> > This patch ensures that the EDID is within the spec (specifically, that
> > DC_36bit is set) before committing to going forward with any deep
> > colors.  There was already a check for this EDID inconsistency, but it
> > resulted only in a warning and did not fall-back to safer settings.
> >
> > CC: Ville Syrjälä 
> > Signed-off-by: Nicholas Sielicki 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 35 +++
> >  1 file changed, 23 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 336be31ff3de..42ce3f54d2dc 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3772,30 +3772,34 @@ static void drm_parse_hdmi_deep_color_info(struct
> drm_connector *connector,
> >  {
> >   struct drm_display_info *info = >display_info;
> >   unsigned int dc_bpc = 0;
> > + u8 modes = 0;
> >
> >   /* HDMI supports at least 8 bpc */
> >   info->bpc = 8;
> >
> > + /* Ensure all DC modes are unset if we return early */
> > + info->edid_hdmi_dc_modes = 0;
>
> Clearing this in drm_add_display_info() should be sufficient since
> this guy doesn't get called from anywhere else. So this part could
> be droppped.
>
> Otherwise this feels like a decent way to handle the problem. We
> could of course try to use the 10bpc (or whatever) deep color modes
> the sink claims to support, but given that the people designing the
> thing didn't bother reading the spec, it seems safer to just disable
> deep color support entirely.
>
> Reviewed-by: Ville Syrjälä 
>
> > +
> >   if (cea_db_payload_len(hdmi) < 6)
> >   return;
> >
> >   if (hdmi[6] & DRM_EDID_HDMI_DC_30) {
> >   dc_bpc = 10;
> > - info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_30;
> > + modes |= DRM_EDID_HDMI_DC_30;
> >   DRM_DEBUG("%s: HDMI sink does deep color 30.\n",
> > connector->name);
> >   }
> >
> >   if (hdmi[6] & DRM_EDID_HDMI_DC_36) {
> >   dc_bpc = 12;
> > - info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_36;
> > + modes |= DRM_EDID_HDMI_DC_36;
> >   DRM_DEBUG("%s: HDMI sink does deep color 36.\n",
> > connector->name);
> >   }
> >
> >   if (hdmi[6] & DRM_EDID_HDMI_DC_48) {
> >   dc_bpc = 16;
> > - info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_48;
> > + modes |= DRM_EDID_HDMI_DC_48;
> >   DRM_DEBUG("%s: HDMI sink does deep color 48.\n",
> > connector->name);
> >   }
> > @@ -3806,9 +3810,24 @@ static void drm_parse_hdmi_deep_color_info(struct
> drm_connector *connector,
> >   return;
> >   }
> >
> > + /*
> > +  * All deep color modes are optional, but if a sink supports any
> deep
> > +  * color mode, it must support 36-bit mode. If this is found not
> > +  * to be the case, sink is in violation of HDMI 1.3 / 1.4 spec and
> it
> > +  * is prudent to disable all deep color modes. Return here before
> > +  * committing bpc and edid_hdmi_dc_modes.
> > +  */
> > + if (!(modes & DRM_EDID_HDMI_DC_36)) {
> > + DRM_DEBUG("%s: HDMI sink should do DC_36, but does not!\n",
> > +   connector->name);
> > + return;
> > + }
> > +
> > +
> >   DRM_DEBUG("%s: Assigning HDMI sink color depth as %d bpc.\n",
> > connector->name, dc_bpc);
> >   info->bpc = dc_bpc;
> > + info->edid_hdmi_dc_modes = modes;
> >
> >   /*
> >* Deep color support mandates RGB444 support for all video
> > @@ -3823,15 +3842,6 @@ static void drm_parse_hdmi_deep_color_info(struct
> drm_connector *connector,
> >   

[RFC] Using DC in amdgpu for upcoming GPU

[Ernst Sjöstrand]

2016-12-13 3:33 GMT+01:00 Harry Wentland :

Please keep asking us to get on dri-devel with questions. I need to get
> into the habit again of leaving the IRC channel open. I think most of us
> are still a bit scared of it or don't know how to deal with some of the
> information overload (IRC and mailing list). It's some of my job to change
> that all the while I'm learning this myself. :)
>

https://www.irccloud.com/ is pretty nice if you're not the
keep-irssi-running-in-screen-on-a-server type.

Regards
//Ernst
-- next part --
An HTML attachment was scrubbed...
URL: 

AMD guys: commit messages?

[Ernst Sjöstrand]

Hello list!

I lurk here and try to follow Mesa/DRI and most specifically Radeon
driver development, report bugs, test new stuff and help get the bugs
closed and so on...

However I see that the commit messages for AMD/Radeon are often very
unhelpful. They don't state the motivation behind the commits. Is this
a optimization, a nice-to-have cleanup or does this actually fix
something? What does this fix?
Are there tests or bugreports related?

Improving this could make it easier for new developers to start
contributing in the long run also!

Examples:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=d5a5dbd71f0e8756494809025ba2119efdf26373
http://cgit.freedesktop.org/mesa/mesa/commit/?id=338d7bf0531a10d90db75ad333f7e0a31693641f
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4ebcf5194d98b47bd9e8a72b7418054708b14750

This is also in the mesa dev guidelines, www.mesa3d.org/devinfo.html :
"Patch fix is not clearly described. For example, a commit message of
only a single line, no description of the bug, no mention of bugzilla,
etc."

Regards!
//Ernst

Implementing Miracast?

[Ernst Sjöstrand]

Sorry if this is completely off-topic, but could this be useful for
high performance screen recording also?
This seems to be all the rage on Windows these days, with software like
OBS (+AMD VCE support), Nvidia ShadowPlay (also HW accel encoding),
Xsplit, Twitch etc...

Regards
//Ernst

2015-12-04 9:07 GMT+01:00 Daniel Vetter :
> On Thu, Dec 03, 2015 at 07:26:31PM +0200, Martin Peres wrote:
>> On 03/12/15 18:38, Ilia Mirkin wrote:
>> >On Thu, Dec 3, 2015 at 11:10 AM, Laurent Pinchart
>> > wrote:
>> >>Hi Ilia,
>> >>
>> >>On Thursday 03 December 2015 11:03:28 Ilia Mirkin wrote:
>> >>>On Thu, Dec 3, 2015 at 10:53 AM, Laurent Pinchart wrote:
>> On Thursday 03 December 2015 10:42:50 Ilia Mirkin wrote:
>> >On Thu, Dec 3, 2015 at 10:34 AM, Laurent Pinchart wrote:
>> >>On Thursday 03 December 2015 14:42:51 Hannikainen, Jaakko wrote:
>> >>>Hello,
>> >>>
>> >>>We're developing Miracast (HDMI over Wireless connections). The
>> >>>current progress is that it 'works' in the userspace but doesn't have
>> >>>any integration with X/Wayland and can only mirror the current desktop
>> >>>using gstreamer.
>> >>>
>> >>>We're looking into extending the implementation so that we would be
>> >>>able to use the remote screens just as any other connected screen, but
>> >>>we're not quite sure where we should implement it.
>> >>>
>> >>>The DRM interface seems like the perfect fit since we wouldn't need to
>> >>>patch every compositor.
>> >>>
>> >>>Right now, gstreamer is the equivalent of the crtc/encoder, in the DRM
>> >>>model. Screens / crtcs are discovered using a WiFi's p2p protocol
>> >>>which means that screens should be hotpluggable. Since we cannot
>> >>>change the number of crtcs of a driver on the fly, we propose adding
>> >>>and removing gpus with one crtc attached and no rendering
>> >>>capabilities.
>> >>>
>> >>>Compositors and X currently use udev to list gpus and get run-time
>> >>>events for gpu hot-plugging (see the work from Dave Airlie for USB
>> >>>GPUs, using the modesetting X driver). We did not find a way to tell
>> >>>udev that we have a new device and it seems like the only way to get
>> >>>it to pick up our driver is from a uevent which can only be generated
>> >>>from the kernel.
>> >>>
>> >>>Since we have so many userspace components, it doesn't make sense to
>> >>>implement the entire driver in the kernel.
>> >>>
>> >>>We would thus need to have a communication from the kernel space to
>> >>>the userspace at least to send the flip commands to the fake crtc.
>> >>>Since we need this, why not implement everything in the userspace and
>> >>>just redirect the ioctls to the userspace driver?
>> >>>
>> >>>This is exactly what fuse / cuse [1] does, with the minor catch that
>> >>>it creates devices in /sys/class/cuse instead of drm. This prevents
>> >>>the wayland compositors and X to pick it up as a normal drm driver...
>> >>>
>> >>>We would thus need to have the drm subsystem create the device nodes
>> >>>for us when the userspace needs to create a new gpu. We could create a
>> >>>node named /dev/dri/cuse_card that, when opened, would allocate a node
>> >>>(/dev/dri/cardX) and would use cuse/fuse to redirect the ioctls to the
>> >>>process who opened /dev/dri/cuse_card.
>> >>>
>> >>>The process would then be responsible for decoding the ioctl and
>> >>>implementing the drm API.
>> >>>
>> >>>Since this is a major change which would allow proprietary drivers to
>> >>>be implemented in the userspace and since we may have missed something
>> >>>obvious, we would like to start a discussion on this. What are your
>> >>>thoughts?
>> >>As you raise the issue, how would you prevent proprietary userspace
>> >>drivers to be implemented ? Anything that would allow vendors to
>> >>destroy the Linux graphics ecosystem would receive a big nack from me.
>> >AFAIK the displaylink people already have precisely such a driver -- a
>> >(open-source) kernel module that allows their (closed-source)
>> >userspace blob to present a drm node to pass through modesetting/etc
>> >ioctl's.
>> Are you talking about the drivers/gpu/drm/udl/ driver ? I might be wrong
>> but I'm not aware of that kernel driver requiring a closed-source
>> userspace blob.
>> >>>Nope. That driver only works for their USB2 parts. This is what I mean:
>> >>>
>> >>>https://github.com/DisplayLink/evdi
>> >>>http://support.displaylink.com/knowledgebase/articles/679060
>> >>>http://support.displaylink.com/knowledgebase/articles/615714#ubuntu
>> >>Right. That's out-of-tree, people are free to screw up on their own there 
>> >>;-)
>> >Sure, but it's identical to Jaakko's proposal from what I can
>> >(quickly) tell. And it's an example of someone taking an interface
>> >like that and writing a proprietary 

[PATCH 1/2] amdgpu: fix overflow for timeout calculation

[Ernst Sjöstrand]

Doh, I didn't get that! Sorry.

Regards
//Ernst

2015-11-21 12:07 GMT+01:00 Christian König :

> On 21.11.2015 11:48, Ernst Sjöstrand wrote:
>
> I guess the patches should be for drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> instead?
>
>
> No, why do you think so? This is a libdrm patch, not a kernel patch.
>
> Regards,
> Christian.
>
>
>
> Regards
> //Ernst
>
> 2015-11-21 1:24 GMT+01:00 Alex Deucher :
>
>> From: Jammy Zhou 
>>
>> Set the timeout to AMDGPU_TIMEOUT_INFINITE when overflow happens
>>
>> Signed-off-by: Jammy Zhou 
>> Reviewed-by: Christian König 
>> ---
>>  amdgpu/amdgpu_cs.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
>> index 4da9821..aa594c4 100644
>> --- a/amdgpu/amdgpu_cs.c
>> +++ b/amdgpu/amdgpu_cs.c
>> @@ -289,12 +289,16 @@ drm_private uint64_t
>> amdgpu_cs_calculate_timeout(uint64_t timeout)
>>
>> if (timeout != AMDGPU_TIMEOUT_INFINITE) {
>> struct timespec current;
>> +   uint64_t current_ns;
>> r = clock_gettime(CLOCK_MONOTONIC, );
>> if (r)
>> return r;
>>
>> -   timeout += ((uint64_t)current.tv_sec) * 10ull;
>> -   timeout += current.tv_nsec;
>> +   current_ns = ((uint64_t)current.tv_sec) * 10ull;
>> +   current_ns += current.tv_nsec;
>> +   timeout += current_ns;
>> +   if (timeout < current_ns)
>> +   timeout = AMDGPU_TIMEOUT_INFINITE;
>> }
>> return timeout;
>>  }
>> --
>> 1.8.3.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
>
>
> ___
> dri-devel mailing listdri-devel at 
> lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH 1/2] amdgpu: fix overflow for timeout calculation

[Ernst Sjöstrand]

I guess the patches should be for drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
instead?

Regards
//Ernst

2015-11-21 1:24 GMT+01:00 Alex Deucher :

> From: Jammy Zhou 
>
> Set the timeout to AMDGPU_TIMEOUT_INFINITE when overflow happens
>
> Signed-off-by: Jammy Zhou 
> Reviewed-by: Christian König 
> ---
>  amdgpu/amdgpu_cs.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
> index 4da9821..aa594c4 100644
> --- a/amdgpu/amdgpu_cs.c
> +++ b/amdgpu/amdgpu_cs.c
> @@ -289,12 +289,16 @@ drm_private uint64_t
> amdgpu_cs_calculate_timeout(uint64_t timeout)
>
> if (timeout != AMDGPU_TIMEOUT_INFINITE) {
> struct timespec current;
> +   uint64_t current_ns;
> r = clock_gettime(CLOCK_MONOTONIC, );
> if (r)
> return r;
>
> -   timeout += ((uint64_t)current.tv_sec) * 10ull;
> -   timeout += current.tv_nsec;
> +   current_ns = ((uint64_t)current.tv_sec) * 10ull;
> +   current_ns += current.tv_nsec;
> +   timeout += current_ns;
> +   if (timeout < current_ns)
> +   timeout = AMDGPU_TIMEOUT_INFINITE;
> }
> return timeout;
>  }
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[pull] amdgpu and radeon drm-next-4.4

[Ernst Sjöstrand]

Don't forget https://bugs.freedesktop.org/attachment.cgi?id=118844

"drm/amdgpu: adjust default dispclk (v2)"

Regards
//Ernst


2015-10-14 22:44 GMT+02:00 Alex Deucher :
> Hi Dave,
>
> This is the first radeon and amdgpu pull for drm-next. Highlights include:
> - Efficiency improvements to the CS checker for pre-SI asics
> - Cursor fixes ported from radeon to amdgpu
> - Enable GPU scheduler by default
> - Add a bunch of GPUVM debugging options
> - Add support for some new atombios opcodes
> - Misc cleanups and fixes
>
> The following changes since commit d4070ff71363a2b6598633f23558f809600ebad2:
>
>   Merge tag 'drm-intel-next-2015-09-11' of 
> git://anongit.freedesktop.org/drm-intel into drm-next (2015-10-02 15:41:17 
> +1000)
>
> are available in the git repository at:
>
>
>   git://people.freedesktop.org/~agd5f/linux drm-next-4.4
>
> for you to fetch changes up to 2fcef6ec87a044221fc3c2f16873f7c02b9ae991:
>
>   drm/amdgpu: fix lockup when clean pending fences (2015-10-14 16:20:32 -0400)
>
> 
> Alex Deucher (24):
>   drm/amdgpu: split gfx8 gpu init into sw and hw parts
>   drm/amdgpu: disable hw semaphores by default
>   drm/amdgpu/atom: implement debug opcode
>   drm/amdgpu/atom: add support for process ds opcode
>   drm/amdgpu/atom: add support for new mul32 opcodes (v2)
>   drm/amdgpu/atom: add support for new div32 opcodes (v3)
>   drm/amdgpu/dce10: Use cursor_set2 hook for enabling / disabling the HW 
> cursor
>   drm/amdgpu/dce10: Re-show the cursor after a modeset (v2)
>   drm/amdgpu/dce10: Move hotspot handling out of set_cursor
>   drm/amdgpu/dce10: Clean up reference counting and pinning of the cursor 
> BOs
>   drm/amdgpu/dce10: Fold set_cursor() into show_cursor()
>   drm/amdgpu/dce11: Use cursor_set2 hook for enabling / disabling the HW 
> cursor
>   drm/amdgpu/dce11: Re-show the cursor after a modeset (v2)
>   drm/amdgpu/dce11: Move hotspot handling out of set_cursor
>   drm/amdgpu/dce11: Clean up reference counting and pinning of the cursor 
> BOs
>   drm/amdgpu/dce11: Fold set_cursor() into show_cursor()
>   drm/amdgpu/dce8: Use cursor_set2 hook for enabling / disabling the HW 
> cursor
>   drm/amdgpu/dce8: Re-show the cursor after a modeset (v2)
>   drm/amdgpu/dce8: Move hotspot handling out of set_cursor
>   drm/amdgpu/dce8: Clean up reference counting and pinning of the cursor 
> BOs
>   drm/amdgpu/dce8: Fold set_cursor() into show_cursor()
>   drm/amdgpu: unpin cursor BOs on suspend and pin them again on resume
>   drm/amdgpu: rework sdma structures
>   drm/amdgpu: clean up pageflip interrupt handling
>
> Christian König (5):
>   drm/amdgpu: also trace already allocated VMIDs
>   drm/amdgpu: only print meaningful VM faults
>   drm/amdgpu: add option to stop on VM fault
>   drm/amdgpu: add option to clear VM page tables after every submit
>   drm/amdgpu: add VM CS mapping trace point
>
> Chunming Zhou (3):
>   drm/amdgpu: add vram usage into debugfs
>   drm/amdgpu: add TOPDOWN flag to the whole vram
>   drm/amdgpu: enable scheduler by default
>
> Grazvydas Ignotas (4):
>   drm/radeon: simplify register checker
>   drm/radeon: split evergreen_cs_check_reg
>   drm/radeon: refactor register check loop
>   drm/radeon: remove volatile qualifier
>
> Junwei Zhang (2):
>   drm/amdgpu: add timer to fence to detect scheduler lockup
>   drm/amdgpu: fix lockup when clean pending fences
>
> Lukas Wunner (4):
>   drm/radeon: Spell vga_switcheroo consistently
>   drm/amdgpu: Spell vga_switcheroo consistently
>   drm/radeon: Drop unnecessary #include 
>   drm/amdgpu: Drop unnecessary #include 
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  29 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c  |   1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c  |   1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|  24 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  33 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  16 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c |  14 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  12 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |   4 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|   2 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c  |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h |  12 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |   5 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  12 +-
>  drivers/gpu/drm/amd/amdgpu/atom.c |  53 ++-
>  drivers/gpu/drm/amd/amdgpu/atom.h |   2 +-
>