Re: [PATCH libdrm] amdgpu/basic_tests.c: check for fork

[Koenig, Christian]

AH, enlightenment!

Yeah, the whole kernel driver won't work on no-mmu platforms. So 
compiling the userspace parts doesn't make any sense either.

Thanks for clearing that up, it wasn't obvious to me why we had this 
limitation here.

Regards,
Christian.

Am 11.03.19 um 23:25 schrieb Fabrice Fontaine:
> OK, thanks for your input, I'll disable amdgpu on platforms without MMU.
>
> Fabrice
>
>
> Le lun. 11 mars 2019 à 18:40, Koenig, Christian
>  a écrit :
>> Am 11.03.19 um 18:17 schrieb Fabrice Fontaine:
>>> OK, then will you accept a patch that disable amdgpu test if fork is
>>> not available or a patch that disable all tests (for example through a
>>> --disable-test-programs option)?
>> No, we really need to test the correct behavior of fork() with userptrs.
>>
>> So how do we spawn a child process with uclibc-ng?
>>
>> I mean it is one of the most fundamental Unix functions, isn't it?
>>
>> Christian.
>>
>>>Currently, the user can only disable
>>> the cairo tests so the whole libdrm package fails to statically build
>>> with uclibc-ng on ARM cortex M4
>>> (http://autobuild.buildroot.org/?reason=libdrm-2.4.97).
>>>
>>> Best Regards,
>>>
>>> Fabrice
>>>
>>> Le lun. 11 mars 2019 à 17:40, Christian König
>>>  a écrit :
 Well NAK, cause that obviously would break the test if fork() isn't
 available.

 We certainly don't have any platform where we support amdgpu and fork()
 is not available, so that change is rather pointless in the first place.

 Christian.

 Am 10.03.19 um 10:44 schrieb Fabrice Fontaine:
> amdgpu test program use fork since
> https://cgit.freedesktop.org/mesa/drm/commit/tests/amdgpu/basic_tests.c?id=736ef0b61cab55378202c5f49d91799cc2b99091
>
> However, this function is not always available so add a check for it in
> configure.ac and use it in tests/amdgpu/basic_tests.c
>
> Fixes:
> - 
> http://autobuild.buildroot.org/results/8d6194982c1080e173fcef8212fb06e6dc275d58
>
> Signed-off-by: Fabrice Fontaine 
> ---
> configure.ac   | 2 ++
> tests/amdgpu/basic_tests.c | 4 
> 2 files changed, 6 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index d72e84ad..6effb9a2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -193,6 +193,8 @@ AC_CHECK_FUNCS([open_memstream],
>[AC_DEFINE([HAVE_OPEN_MEMSTREAM], 1, [Have 
> open_memstream()])],
>[AC_DEFINE([HAVE_OPEN_MEMSTREAM], 0)])
>
> +AC_CHECK_FUNCS([fork])
> +
> dnl Use lots of warning flags with with gcc and compatible compilers
>
> dnl Note: if you change the following variable, the cache is 
> automatically
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index dbae4d53..c32a1351 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -1646,10 +1646,12 @@ static void amdgpu_userptr_test(void)
> while (j++ < sdma_write_length)
> pm4[i++] = 0xdeadbeaf;
>
> +#ifdef HAVE_FORK
> if (!fork()) {
> pm4[0] = 0x0;
> exit(0);
> }
> +#endif
>
> amdgpu_test_exec_cs_helper(context_handle,
>AMDGPU_HW_IP_DMA, 0,
> @@ -1675,7 +1677,9 @@ static void amdgpu_userptr_test(void)
> r = amdgpu_cs_ctx_free(context_handle);
> CU_ASSERT_EQUAL(r, 0);
>
> +#ifdef HAVE_FORK
> wait(NULL);
> +#endif
> }
>
> static void amdgpu_sync_dependency_test(void)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/2] drm/sched: Refactor ring mirror list handling.

[Tomeu Vizoso]

On Thu, 27 Dec 2018 at 20:28, Andrey Grodzovsky
 wrote:
>
> Decauple sched threads stop and start and ring mirror
> list handling from the policy of what to do about the
> guilty jobs.
> When stoppping the sched thread and detaching sched fences
> from non signaled HW fenes wait for all signaled HW fences
> to complete before rerunning the jobs.
>
> v2: Fix resubmission of guilty job into HW after refactoring.
>
> v4:
> Full restart for all the jobs, not only from guilty ring.
> Extract karma increase into standalone function.
>
> v5:
> Rework waiting for signaled jobs without relying on the job
> struct itself as those might already be freed for non 'guilty'
> job's schedulers.
> Expose karma increase to drivers.
>
> v6:
> Use list_for_each_entry_safe_continue and drm_sched_process_job
> in case fence already signaled.
> Call drm_sched_increase_karma only once for amdgpu and add documentation.
>
> Suggested-by: Christian Koenig 
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  20 ++-
>  drivers/gpu/drm/etnaviv/etnaviv_sched.c|  11 +-
>  drivers/gpu/drm/scheduler/sched_main.c | 195 
> +++--
>  drivers/gpu/drm/v3d/v3d_sched.c|  12 +-
>  include/drm/gpu_scheduler.h|   8 +-
>  5 files changed, 157 insertions(+), 89 deletions(-)
>
[snip]
> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
> index 445b2ef..f76d9ed 100644
> --- a/drivers/gpu/drm/v3d/v3d_sched.c
> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
> @@ -178,18 +178,22 @@ v3d_job_timedout(struct drm_sched_job *sched_job)
> for (q = 0; q < V3D_MAX_QUEUES; q++) {
> struct drm_gpu_scheduler *sched = &v3d->queue[q].sched;
>
> -   kthread_park(sched->thread);
> -   drm_sched_hw_job_reset(sched, (sched_job->sched == sched ?
> +   drm_sched_stop(sched, (sched_job->sched == sched ?
>sched_job : NULL));
> +
> +   if(sched_job)
> +   drm_sched_increase_karma(sched_job);
> }
>
> /* get the GPU back into the init state */
> v3d_reset(v3d);
>
> +   for (q = 0; q < V3D_MAX_QUEUES; q++)
> +   drm_sched_resubmit_jobs(sched_job->sched);

Hi Andrey,

I'm not sure of what was the original intent, but I guess it wasn't to
repeatedly call resubmit_jobs on that specific job's queue?

Regards,

Tomeu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: INFO: rcu detected stall in sys_sendfile64 (2)

[Jani Nikula]

On Tue, 12 Mar 2019, Al Viro  wrote:
> On Mon, Mar 11, 2019 at 08:59:00PM -0700, syzbot wrote:
>> syzbot has bisected this bug to:
>> 
>> commit 34e07e42c55aeaa78e93b057a6664e2ecde3fadb
>> Author: Chris Wilson 
>> Date:   Thu Feb 8 10:54:48 2018 +
>> 
>> drm/i915: Add missing kerneldoc for 'ent' in i915_driver_init_early
>> 
>> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1322028320
>> start commit:   34e07e42 drm/i915: Add missing kerneldoc for 'ent' in i915..
>> git tree:   upstream
>> final crash:https://syzkaller.appspot.com/x/report.txt?x=10a2028320
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1722028320
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=abc3dc9b7a900258
>> dashboard link: https://syzkaller.appspot.com/bug?extid=1505c80c74256c6118a5
>> userspace arch: amd64
>> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=12c4dc28c0
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15df4108c0
>> 
>> Reported-by: syzbot+1505c80c74256c611...@syzkaller.appspotmail.com
>> Fixes: 34e07e42 ("drm/i915: Add missing kerneldoc for 'ent' in
>> i915_driver_init_early")
>
> Umm...  Might be a good idea to add some plausibility filters - it is,
> in theory, possible that adding a line in a comment changes behaviour
> (without compiler bugs, even - playing with __LINE__ is all it would
> take), but the odds that it's _not_ a false positive are very low.

If it's not a false positive, it's bound to be good source material for
IOCCC.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/udl: Bugfix in EDID reading routine

[Jani Nikula]

On Mon, 11 Mar 2019, Robert Tarasov  wrote:
> Yes, you're right. Will prepare another patch which will use
> drm_do_get_edid()

Oh, you might want to have this patch first with cc: stable and all
that, and do the cleanup afterwards.

BR,
Jani.


>
> On Mon, Mar 11, 2019 at 4:33 AM Jani Nikula 
> wrote:
>
>> On Fri, 08 Mar 2019, Robert Tarasov  wrote:
>> > Fixed bug with reading of last EDID extra block in drm/udl driver.
>> > Previouse approach read all the blocks except the last one.
>> >
>> > Signed-off-by: Robert Tarasov 
>> > ---
>> >  drivers/gpu/drm/udl/udl_connector.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/udl/udl_connector.c
>> b/drivers/gpu/drm/udl/udl_connector.c
>> > index c3dc1fd20cb4..68b221b9a01f 100644
>> > --- a/drivers/gpu/drm/udl/udl_connector.c
>> > +++ b/drivers/gpu/drm/udl/udl_connector.c
>> > @@ -70,7 +70,7 @@ static bool udl_get_edid(struct udl_device *udl, u8
>> **result_buff,
>> >   memcpy(buff_ptr, block_buff, EDID_LENGTH);
>> >   kfree(block_buff);
>> >   buff_ptr += EDID_LENGTH;
>> > - for (i = 1; i < extensions; ++i) {
>> > + for (i = 1; i <= extensions; ++i) {
>> >   if (udl_get_edid_block(udl, i, buff_ptr)) {
>> >   buff_ptr += EDID_LENGTH;
>> >   } else {
>>
>> Ugh. Why doesn't udl use drm_do_get_edid()?
>>
>> BR,
>> Jani.
>>
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
>>

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8] drm/lima: driver for ARM Mali4xx GPUs

[Heiko Stuebner]

Hi,

Am Dienstag, 12. März 2019, 02:54:57 CET schrieb Qiang Yu:
> On Mon, Mar 11, 2019 at 11:37 PM Rob Herring  wrote:
> >
> > On Sat, Mar 9, 2019 at 6:21 AM Qiang Yu  wrote:
> > >
> > > - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> > >   OpenGL vertex shader processing and PP is for fragment shader
> > >   processing. Each processor has its own MMU so prcessors work in
> > >   virtual address space.
> > > - There's only one GP but multiple PP (max 4 for mali 400 and 8
> > >   for mali 450) in the same mali 4xx GPU. All PPs are grouped
> > >   togather to handle a single fragment shader task divided by
> > >   FB output tiled pixels. Mali 400 user space driver is
> > >   responsible for assign target tiled pixels to each PP, but mali
> > >   450 has a HW module called DLBU to dynamically balance each
> > >   PP's load.
> > > - User space driver allocate buffer object and map into GPU
> > >   virtual address space, upload command stream and draw data with
> > >   CPU mmap of the buffer object, then submit task to GP/PP with
> > >   a register frame indicating where is the command stream and misc
> > >   settings.
> > > - There's no command stream validation/relocation due to each user
> > >   process has its own GPU virtual address space. GP/PP's MMU switch
> > >   virtual address space before running two tasks from different
> > >   user process. Error or evil user space code just get MMU fault
> > >   or GP/PP error IRQ, then the HW/SW will be recovered.
> > > - Use GEM+shmem for MM. Currently just alloc and pin memory when
> > >   gem object creation. GPU vm map of the buffer is also done in
> > >   the alloc stage in kernel space. We may delay the memory
> > >   allocation and real GPU vm map to command submission stage in the
> > >   furture as improvement.
> > > - Use drm_sched for GPU task schedule. Each OpenGL context should
> > >   have a lima context object in the kernel to distinguish tasks
> > >   from different user. drm_sched gets task from each lima context
> > >   in a fair way.
> > >
> > > mesa driver can be found here before upstreamed:
> > > https://gitlab.freedesktop.org/lima/mesa
> > >
> > > v8:
> > > - add comments for in_sync
> > > - fix ctx free miss mutex unlock
> > >
> > > v7:
> > > - remove lima_fence_ops with default value
> > > - move fence slab create to device probe
> > > - check pad ioctl args to be zero
> > > - add comments for user/kernel interface
> > >
> > > v6:
> > > - fix comments by checkpatch.pl
> > >
> > > v5:
> > > - export gp/pp version to userspace
> > > - rebase on drm-misc-next
> > >
> > > v4:
> > > - use get param interface to get info
> > > - separate context create/free ioctl
> > > - remove unused max sched task param
> > > - update copyright time
> > > - use xarray instead of idr
> > > - stop using drmP.h
> > >
> > > v3:
> > > - fix comments from kbuild robot
> > > - restrict supported arch to tested ones
> > >
> > > v2:
> > > - fix syscall argument check
> > > - fix job finish fence leak since kernel 5.0
> > > - use drm syncobj to replace native fence
> > > - move buffer object GPU va map into kernel
> > > - reserve syscall argument space for future info
> > > - remove kernel gem modifier
> > > - switch TTM back to GEM+shmem MM
> > > - use time based io poll
> > > - use whole register name
> > > - adopt gem reservation obj integration
> > > - use drm_timeout_abs_to_jiffies
> > >
> > > Cc: Eric Anholt 
> > > Cc: Rob Herring 
> > > Cc: Christian König 
> > > Cc: Daniel Vetter 
> > > Cc: Alex Deucher 
> > > Cc: Sam Ravnborg 
> > > Cc: Rob Clark 
> > > Cc: Dave Airlie 
> > > Signed-off-by: Andreas Baierl 
> > > Signed-off-by: Erico Nunes 
> > > Signed-off-by: Heiko Stuebner 
> > > Signed-off-by: Marek Vasut 
> > > Signed-off-by: Neil Armstrong 
> > > Signed-off-by: Simon Shields 
> > > Signed-off-by: Vasily Khoruzhick 
> > > Signed-off-by: Qiang Yu 
> > > Reviewed-by: Eric Anholt 
> > > Reviewed-by: Rob Herring 
> > > ---
> >
> > [...]
> 
> I thought get your RB last time, should I remove it?

I read Rob's comment as "if you need to resent for any other reason
then you could modify for that patch, but no need to resend everything
just for this", so a RB can probably stay as it is.


Heiko

> > Not to make you keep shooting for a moving target, Eric just posted a
> > patch[1] a few days ago that can replace these 2 functions. Would be
> > good to use if you respin, but otherwise can be a follow-on patch.
> 
> Thanks for the remind.
> 
> Regards,
> Qiang




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105733

Allan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #80 from Allan  ---
Closing this issue, here is the summary for a quick look:

The problem : amdgpu hangs suddenly, nothing can kill it.

Solution : The driver got more stable over time.

The causes :
1 - The driver itself was more unstable.
2 - The kernel wasn't supporting ryzen CPUs properly, leading to segfaults and
unexpected behaviors. If it is your case, use any kernel already listed here.
3 - Corsair RAM is not a good deal to work with Ryzen, specially if they don't
have some kind of "Ryzen ready" seal. Aiming the best performance for Intel
platforms made them to not support JEDEC standards properly while trying to use
the SPD profile, even if you try to delay latencies.
Thus, bad RAM -> unexpected behaviors, including from the driver.

Additional information :
I was able to test only a few days (a week or so) before the GPU showed BGA
problems.
It was working fine.

If I ever be able to test it again and find another scenario where the driver
hangs and can't be killed I'll report here.

-- 
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 109970] Personal Banking Button Is Not available

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109970

Michel Dänzer  changed:

   What|Removed |Added

Product|DRI |Spam
Version|DRI git |unspecified
   Assignee|dri-devel@lists.freedesktop |dan...@fooishbar.org
   |.org|
  Component|DRM/other   |Two

-- 
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 1/5] drm: don't block fb changes for async plane updates

[Boris Brezillon]

On Mon, 11 Mar 2019 20:51:27 +0100
Daniel Vetter  wrote:

> On Mon, Mar 11, 2019 at 03:20:09PM +0100, Boris Brezillon wrote:
> > On Mon, 11 Mar 2019 13:15:23 +
> > "Kazlauskas, Nicholas"  wrote:
> >   
> > > On 3/11/19 6:06 AM, Boris Brezillon wrote:  
> > > > Hello Nicholas,
> > > > 
> > > > On Mon, 4 Mar 2019 15:46:49 +
> > > > "Kazlauskas, Nicholas"  wrote:
> > > > 
> > > >> On 3/4/19 9:49 AM, Helen Koike wrote:
> > > >>> In the case of a normal sync update, the preparation of framebuffers 
> > > >>> (be
> > > >>> it calling drm_atomic_helper_prepare_planes() or doing setups with
> > > >>> drm_framebuffer_get()) are performed in the new_state and the 
> > > >>> respective
> > > >>> cleanups are performed in the old_state.
> > > >>>
> > > >>> In the case of async updates, the preparation is also done in the
> > > >>> new_state but the cleanups are done in the new_state (because updates
> > > >>> are performed in place, i.e. in the current state).
> > > >>>
> > > >>> The current code blocks async udpates when the fb is changed, turning
> > > >>> async updates into sync updates, slowing down cursor updates and
> > > >>> introducing regressions in igt tests with errors of type:
> > > >>>
> > > >>> "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
> > > >>> expect to complete approximately 15360 updates, with the threshold set
> > > >>> at 7680"
> > > >>>
> > > >>> Fb changes in async updates were prevented to avoid the following 
> > > >>> scenario:
> > > >>>
> > > >>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
> > > >>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
> > > >>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup 
> > > >>> fb2 (wrong)
> > > >>> Where we have a single call to prepare fb2 but double cleanup call to 
> > > >>> fb2.
> > > >>>
> > > >>> To solve the above problems, instead of blocking async fb changes, we
> > > >>> place the old framebuffer in the new_state object, so when the code
> > > >>> performs cleanups in the new_state it will cleanup the old_fb and we
> > > >>> will have the following scenario instead:
> > > >>>
> > > >>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
> > > >>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
> > > >>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
> > > >>>
> > > >>> Where calls to prepare/cleanup are ballanced.
> > > >>>
> > > >>> Cc:  # v4.14+: 25dc194b34dd: drm: Block fb 
> > > >>> changes for async plane updates
> > > >>> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
> > > >>> Suggested-by: Boris Brezillon 
> > > >>> Signed-off-by: Helen Koike 
> > > >>>
> > > >>> ---
> > > >>> Hello,
> > > >>>
> > > >>> As mentioned in the cover letter,
> > > >>> I tested on the rockchip and on i915 (with a patch I am still working 
> > > >>> on for
> > > >>> replacing cursors by async update), with igt plane_cursor_legacy and
> > > >>> kms_cursor_legacy and I didn't see any regressions.
> > > >>> I couldn't test on MSM and AMD because I don't have the hardware (and 
> > > >>> I am
> > > >>> having some issues testing on vc4) and I would appreciate if anyone 
> > > >>> could help
> > > >>> me testing those.
> > > >>>
> > > >>> I also think it would be a better solution if, instead of having async
> > > >>> to do in-place updates in the current state, the async path should be
> > > >>> equivalent to a syncronous update, i.e., modifying new_state and
> > > >>> performing a flip
> > > >>> IMHO, the only difference between sync and async should be that async 
> > > >>> update
> > > >>> doesn't wait for vblank and applies the changes immeditally to the hw,
> > > >>> but the code path could be almost the same.
> > > >>> But for now I think this solution is ok (swaping new_fb/old_fb), and
> > > >>> then we can adjust things little by little, what do you think?
> > > >>>
> > > >>> Thanks!
> > > >>> Helen
> > > >>>
> > > >>>drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
> > > >>>1 file changed, 10 insertions(+), 10 deletions(-)
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > >>> b/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> index 540a77a2ade9..e7eb96f1efc2 100644
> > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> @@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct 
> > > >>> drm_device *dev,
> > > >>>   old_plane_state->crtc != new_plane_state->crtc)
> > > >>>   return -EINVAL;
> > > >>>
> > > >>> - /*
> > > >>> -  * FIXME: Since prepare_fb and cleanup_fb are always called on
> > > >>> -  * the new_plane_state for async updates we need to block 
> > > >>> framebuffer
> > > >>> -  * changes. This prevents use of a fb that's been cleaned up and
> > > >>> -  * double cleanups from occuring.
> > > >>> -  */
> > > 

Re: [PATCH] drm/udl: Bugfix in EDID reading routine

[Robert Tarasov]

Yes, you're right. Will prepare another patch which will use
drm_do_get_edid()

On Mon, Mar 11, 2019 at 4:33 AM Jani Nikula 
wrote:

> On Fri, 08 Mar 2019, Robert Tarasov  wrote:
> > Fixed bug with reading of last EDID extra block in drm/udl driver.
> > Previouse approach read all the blocks except the last one.
> >
> > Signed-off-by: Robert Tarasov 
> > ---
> >  drivers/gpu/drm/udl/udl_connector.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/udl/udl_connector.c
> b/drivers/gpu/drm/udl/udl_connector.c
> > index c3dc1fd20cb4..68b221b9a01f 100644
> > --- a/drivers/gpu/drm/udl/udl_connector.c
> > +++ b/drivers/gpu/drm/udl/udl_connector.c
> > @@ -70,7 +70,7 @@ static bool udl_get_edid(struct udl_device *udl, u8
> **result_buff,
> >   memcpy(buff_ptr, block_buff, EDID_LENGTH);
> >   kfree(block_buff);
> >   buff_ptr += EDID_LENGTH;
> > - for (i = 1; i < extensions; ++i) {
> > + for (i = 1; i <= extensions; ++i) {
> >   if (udl_get_edid_block(udl, i, buff_ptr)) {
> >   buff_ptr += EDID_LENGTH;
> >   } else {
>
> Ugh. Why doesn't udl use drm_do_get_edid()?
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] dt-bindings: display: amlogic, meson-vpu: exclusively use amlogic, canvas

[Maxime Jourdan]

When the DRM driver for the meson platform was created, the bindings
required that the DMC register region was provided.

Through those DMC registers, the display driver could configure an IP
called "canvas", a video lookup table used by the display IP.

It was later discovered that "canvas" is actually an IP shared by other
components than display: video decoder, 2D engine.. and that it wasn't
possible to keep the canvas code in DRM.

Over the past few months, incremental efforts have been deployed to
create a standalone meson-canvas driver [1], and the DRM driver was
patched to optionally use it if present [2].

This is the final step of those efforts where we simply remove any
control over DMC that the meson DRM driver has.

Please note that this breaks compatibility with older DTs that only
provide the DMC register range but not the amlogic,canvas node.

[1] https://patchwork.kernel.org/cover/10573771/
[2] https://patchwork.freedesktop.org/series/52076/

Signed-off-by: Maxime Jourdan 
---
 .../devicetree/bindings/display/amlogic,meson-vpu.txt| 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt 
b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
index c65fd7a7467c..419444e2b4d3 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
@@ -60,15 +60,14 @@ Required properties:
 - reg: base address and size of he following memory-mapped regions :
- vpu
- hhi
-   - dmc
 - reg-names: should contain the names of the previous memory regions
 - interrupts: should contain the VENC Vsync interrupt number
+- amlogic,canvas: phandle to canvas provider node as described in the file
+   ../soc/amlogic/amlogic,canvas.txt
 
 Optional properties:
 - power-domains: Optional phandle to associated power domain as described in
the file ../power/power_domain.txt
-- amlogic,canvas: phandle to canvas provider node as described in the file
-   ../soc/amlogic/amlogic,canvas.txt
 
 Required nodes:
 
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: WARNING in vkms_vblank_simulate

[Dmitry Vyukov]

On Mon, Mar 11, 2019 at 1:28 PM syzbot
 wrote:
>
> syzbot has bisected this bug to:
>
> commit 09ef09b4ab95dc405ad4171ec2cd8a4ff5227108
> Author: Shayenne Moura 
> Date:   Wed Feb 6 20:08:13 2019 +
>
>  drm/vkms: WARN when hrtimer_forward_now fails

+Shayenne

This should have been included the author email when mailed by the
bot. This should be fixed now, tests added. Sorry for the churn.


> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=128448cf20
> start commit:   09ef09b4 drm/vkms: WARN when hrtimer_forward_now fails
> git tree:   upstream
> final crash:https://syzkaller.appspot.com/x/report.txt?x=118448cf20
> console output: https://syzkaller.appspot.com/x/log.txt?x=168448cf20
> kernel config:  https://syzkaller.appspot.com/x/.config?x=c1e0e0ec44d1e5ff
> dashboard link: https://syzkaller.appspot.com/bug?extid=0871b14ca2e2fb64f6e3
> userspace arch: amd64
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1787db8d20
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17fc988320
>
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Fixes: 09ef09b4 ("drm/vkms: WARN when hrtimer_forward_now fails")
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/syzkaller-bugs/11f13c0583d0b48c%40google.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: INFO: rcu detected stall in sys_sendfile64 (2)

[Al Viro]

On Mon, Mar 11, 2019 at 08:59:00PM -0700, syzbot wrote:
> syzbot has bisected this bug to:
> 
> commit 34e07e42c55aeaa78e93b057a6664e2ecde3fadb
> Author: Chris Wilson 
> Date:   Thu Feb 8 10:54:48 2018 +
> 
> drm/i915: Add missing kerneldoc for 'ent' in i915_driver_init_early
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1322028320
> start commit:   34e07e42 drm/i915: Add missing kerneldoc for 'ent' in i915..
> git tree:   upstream
> final crash:https://syzkaller.appspot.com/x/report.txt?x=10a2028320
> console output: https://syzkaller.appspot.com/x/log.txt?x=1722028320
> kernel config:  https://syzkaller.appspot.com/x/.config?x=abc3dc9b7a900258
> dashboard link: https://syzkaller.appspot.com/bug?extid=1505c80c74256c6118a5
> userspace arch: amd64
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=12c4dc28c0
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15df4108c0
> 
> Reported-by: syzbot+1505c80c74256c611...@syzkaller.appspotmail.com
> Fixes: 34e07e42 ("drm/i915: Add missing kerneldoc for 'ent' in
> i915_driver_init_early")

Umm...  Might be a good idea to add some plausibility filters - it is,
in theory, possible that adding a line in a comment changes behaviour
(without compiler bugs, even - playing with __LINE__ is all it would
take), but the odds that it's _not_ a false positive are very low.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/9] drm/bridge: tc358767: Simplify tc_set_video_mode()

[Andrey Smirnov]

On Mon, Mar 4, 2019 at 4:26 AM Laurent Pinchart
 wrote:
>
> Hi Andrey,
>
> Thank you for the patch.
>
> On Tue, Feb 26, 2019 at 11:36:03AM -0800, Andrey Smirnov wrote:
> > Simplify tc_set_video_mode() by replacing repreated calls to
> > tc_write()/regmap_write() with a single call regmap_multi_reg_write().
> > No functional change intended.
> >
> > Signed-off-by: Andrey Smirnov 
> > Cc: Archit Taneja 
> > Cc: Andrzej Hajda 
> > Cc: Laurent Pinchart 
> > Cc: Chris Healy 
> > Cc: Lucas Stach 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-ker...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/bridge/tc358767.c | 125 --
> >  1 file changed, 65 insertions(+), 60 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> > b/drivers/gpu/drm/bridge/tc358767.c
> > index 86ebd49194b7..c85468fcc157 100644
> > --- a/drivers/gpu/drm/bridge/tc358767.c
> > +++ b/drivers/gpu/drm/bridge/tc358767.c
> > @@ -641,10 +641,6 @@ static int tc_get_display_props(struct tc_data *tc)
> >
> >  static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode 
> > *mode)
> >  {
> > - int ret;
> > - int vid_sync_dly;
> > - int max_tu_symbol;
> > -
> >   int left_margin = mode->htotal - mode->hsync_end;
> >   int right_margin = mode->hsync_start - mode->hdisplay;
> >   int hsync_len = mode->hsync_end - mode->hsync_start;
> > @@ -653,76 +649,85 @@ static int tc_set_video_mode(struct tc_data *tc, 
> > struct drm_display_mode *mode)
> >   int vsync_len = mode->vsync_end - mode->vsync_start;
> >
> >   /*
> > -  * Recommended maximum number of symbols transferred in a transfer 
> > unit:
> > +  * Recommended maximum number of symbols transferred in a
> > +  * transfer unit:
> >* DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
> >*  (output active video bandwidth in bytes))
> >* Must be less than tu_size.
> >*/
> > - max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
> > -
> > - dev_dbg(tc->dev, "set mode %dx%d\n",
> > - mode->hdisplay, mode->vdisplay);
> > - dev_dbg(tc->dev, "H margin %d,%d sync %d\n",
> > - left_margin, right_margin, hsync_len);
> > - dev_dbg(tc->dev, "V margin %d,%d sync %d\n",
> > - upper_margin, lower_margin, vsync_len);
> > - dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal);
> > -
> > + int max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
> >
> > + /* DP Main Stream Attributes */
> > + int vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
> >   /*
> >* LCD Ctl Frame Size
> >* datasheet is not clear of vsdelay in case of DPI
> >* assume we do not need any delay when DPI is a source of
> >* sync signals
> >*/
> > - tc_write(VPCTRL0, (0 << 20) /* VSDELAY */ |
> > -  OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
> > - tc_write(HTIM01, (ALIGN(left_margin, 2) << 16) | /* H back porch */
> > -  (ALIGN(hsync_len, 2) << 0));/* Hsync */
> > - tc_write(HTIM02, (ALIGN(right_margin, 2) << 16) |  /* H front porch */
> > -  (ALIGN(mode->hdisplay, 2) << 0)); /* width */
> > - tc_write(VTIM01, (upper_margin << 16) | /* V back porch */
> > -  (vsync_len << 0)); /* Vsync */
> > - tc_write(VTIM02, (lower_margin << 16) | /* V front porch */
> > -  (mode->vdisplay << 0));/* height */
> > - tc_write(VFUEN0, VFUEN);/* update settings */
> > -
> > + u32 vpctrl0 = (0 << 20) /* VSDELAY */ |
> > +   OPXLFMT_RGB888 | FRMSYNC_DISABLED |
> > +   MSF_DISABLED;
> > + u32 htim01 = (ALIGN(left_margin, 2) << 16) | /* H back porch */
> > +  (ALIGN(hsync_len, 2) << 0); /* Hsync */
> > + u32 htim02 = (ALIGN(right_margin, 2) << 16) | /* H front porch */
> > +  (ALIGN(mode->hdisplay, 2) << 0); /* width */
> > + u32 vtim01 = (upper_margin << 16) | /* V back porch */
> > +  (vsync_len << 0); /* Vsync */
> > + u32 vtim02 = (lower_margin << 16) | /* V front porch */
> > +  (mode->vdisplay << 0); /* height */
> >   /* Test pattern settings */
> > - tc_write(TSTCTL,
> > -  (120 << 24) |  /* Red Color component value */
> > -  (20 << 16) |   /* Green Color component value */
> > -  (99 << 8) |/* Blue Color component value */
> > -  (1 << 4) | /* Enable I2C Filter */
> > -  (2 << 0) | /* Color bar Mode */
> > -  0);
> > -
> > - /* DP Main Stream Attributes */
> > - vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
> > - tc_write(DP0_VIDSYNCDELAY,
> > -  (max_tu_symbol << 16) |/* thresh_dly */
> > -  (vid_sync_dly << 0));
> > + u32 tstctl = (120 << 24) |  /* Red Color com

Re: [PATCH] drm: rockchip: add shutdown function to poweroff VOP and HDMI TX

[Johan Jonker]

Hi,

Just found out that this was patched and reverted before.(lol)
The revert was 3 months ago for RK3399 boards, but other processors
like RK3066 are left without shutdown now.

What's the status for a fix?
Keep using the old patch for now?


drm/rockchip: shutdown drm subsystem on shutdown
https://patchwork.kernel.org/patch/10556151/

[for-4.20] Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec"
https://patchwork.kernel.org/patch/10714725/

2019-03-08 19:37 GMT+01:00, Johan Jonker :
> When a MK808 TV-stick with RK3066 processor
> is given a poweroff command, the monitor doesn't turn blank,
> but freezes. The VOP and HDMI share the same power domain,
> so that means that both there clocks were never turned off.
> Fix the disable of the VOP and HDMI TX by adding an extra
> shutdown function that will unbind both drivers.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] drm/meson: only allow using meson-canvas

[Maxime Jourdan]

This patch series aims at removing access to the DMC register range from
the meson DRM driver, and is the final step at fully migrating it to using
the meson canvas provider module.

Please see the commit notes of patch 1/2
"dt-bindings: display: amlogic, meson-vpu: exclusively use amlogic,canvas"
for more information.

This series also incorporates a probing fix proposed by Neil Armstrong [1]
although rewritten because of heavy code changes in the corresponding
location.

[1] https://lkml.org/lkml/2019/2/4/152

Maxime Jourdan (2):
  dt-bindings: display: amlogic, meson-vpu: exclusively use
amlogic,canvas
  drm/meson: exclusively use the canvas provider module

 .../bindings/display/amlogic,meson-vpu.txt|  5 +-
 drivers/gpu/drm/meson/Makefile|  2 +-
 drivers/gpu/drm/meson/meson_canvas.c  | 73 
 drivers/gpu/drm/meson/meson_canvas.h  | 51 ---
 drivers/gpu/drm/meson/meson_crtc.c| 84 ++-
 drivers/gpu/drm/meson/meson_drv.c | 68 ++-
 drivers/gpu/drm/meson/meson_drv.h |  1 -
 drivers/gpu/drm/meson/meson_overlay.c |  8 --
 drivers/gpu/drm/meson/meson_plane.c   |  6 +-
 drivers/gpu/drm/meson/meson_viu.c |  1 -
 10 files changed, 53 insertions(+), 246 deletions(-)
 delete mode 100644 drivers/gpu/drm/meson/meson_canvas.c
 delete mode 100644 drivers/gpu/drm/meson/meson_canvas.h

-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] [v6, 1/2] dt-bindings: panel: Add Boe Himax8279d is 1200x1920, 4-lane MIPI-DSI LCD panel

[Jerry Han]

The Boe Himax8279d is a 8.0" panel with a 1200x1920 resolution and
connected to DSI using four lanes.

V6:
- Add the information of the reviewer

V5:
- Added changelog

V4:
- None

V3:
- None

V2:
- Add compatible device "boe,himax8279d10p" (Sam)
- Add the necessary property descriptions (Sam)

Signed-off-by: Jerry Han 
Reviewed-by: Sam Ravnborg 
Cc: Jitao Shi 
Cc: Derek Basehore 
Cc: Rock wang 
---
 .../bindings/display/panel/boe,himax8279d.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt

diff --git a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt 
b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
new file mode 100644
index 000..3caea21
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
@@ -0,0 +1,24 @@
+Boe Himax8279d 1200x1920 TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,himax8279d8p" and one of: "boe,himax8279d10p"
+- reg: DSI virtual channel of the peripheral
+- enable-gpios: panel enable gpio
+- pp33-gpios: a GPIO phandle for the 3.3v pin that provides the supply voltage
+- pp18-gpios: a GPIO phandle for the 1.8v pin that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   &mipi_dsi {
+   panel {
+   compatible = "boe,himax8279d8p", "boe,himax8279d10p";
+   reg = <0>;
+   backlight = <&backlight>;
+   enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
+   pp33-gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
+   pp18-gpios = <&gpio 36 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] amdgpu/basic_tests.c: check for fork

[Fabrice Fontaine]

OK, thanks for your input, I'll disable amdgpu on platforms without MMU.

Fabrice


Le lun. 11 mars 2019 à 18:40, Koenig, Christian
 a écrit :
>
> Am 11.03.19 um 18:17 schrieb Fabrice Fontaine:
> > OK, then will you accept a patch that disable amdgpu test if fork is
> > not available or a patch that disable all tests (for example through a
> > --disable-test-programs option)?
>
> No, we really need to test the correct behavior of fork() with userptrs.
>
> So how do we spawn a child process with uclibc-ng?
>
> I mean it is one of the most fundamental Unix functions, isn't it?
>
> Christian.
>
> >   Currently, the user can only disable
> > the cairo tests so the whole libdrm package fails to statically build
> > with uclibc-ng on ARM cortex M4
> > (http://autobuild.buildroot.org/?reason=libdrm-2.4.97).
> >
> > Best Regards,
> >
> > Fabrice
> >
> > Le lun. 11 mars 2019 à 17:40, Christian König
> >  a écrit :
> >> Well NAK, cause that obviously would break the test if fork() isn't
> >> available.
> >>
> >> We certainly don't have any platform where we support amdgpu and fork()
> >> is not available, so that change is rather pointless in the first place.
> >>
> >> Christian.
> >>
> >> Am 10.03.19 um 10:44 schrieb Fabrice Fontaine:
> >>> amdgpu test program use fork since
> >>> https://cgit.freedesktop.org/mesa/drm/commit/tests/amdgpu/basic_tests.c?id=736ef0b61cab55378202c5f49d91799cc2b99091
> >>>
> >>> However, this function is not always available so add a check for it in
> >>> configure.ac and use it in tests/amdgpu/basic_tests.c
> >>>
> >>> Fixes:
> >>>- 
> >>> http://autobuild.buildroot.org/results/8d6194982c1080e173fcef8212fb06e6dc275d58
> >>>
> >>> Signed-off-by: Fabrice Fontaine 
> >>> ---
> >>>configure.ac   | 2 ++
> >>>tests/amdgpu/basic_tests.c | 4 
> >>>2 files changed, 6 insertions(+)
> >>>
> >>> diff --git a/configure.ac b/configure.ac
> >>> index d72e84ad..6effb9a2 100644
> >>> --- a/configure.ac
> >>> +++ b/configure.ac
> >>> @@ -193,6 +193,8 @@ AC_CHECK_FUNCS([open_memstream],
> >>>   [AC_DEFINE([HAVE_OPEN_MEMSTREAM], 1, [Have 
> >>> open_memstream()])],
> >>>   [AC_DEFINE([HAVE_OPEN_MEMSTREAM], 0)])
> >>>
> >>> +AC_CHECK_FUNCS([fork])
> >>> +
> >>>dnl Use lots of warning flags with with gcc and compatible compilers
> >>>
> >>>dnl Note: if you change the following variable, the cache is 
> >>> automatically
> >>> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> >>> index dbae4d53..c32a1351 100644
> >>> --- a/tests/amdgpu/basic_tests.c
> >>> +++ b/tests/amdgpu/basic_tests.c
> >>> @@ -1646,10 +1646,12 @@ static void amdgpu_userptr_test(void)
> >>>while (j++ < sdma_write_length)
> >>>pm4[i++] = 0xdeadbeaf;
> >>>
> >>> +#ifdef HAVE_FORK
> >>>if (!fork()) {
> >>>pm4[0] = 0x0;
> >>>exit(0);
> >>>}
> >>> +#endif
> >>>
> >>>amdgpu_test_exec_cs_helper(context_handle,
> >>>   AMDGPU_HW_IP_DMA, 0,
> >>> @@ -1675,7 +1677,9 @@ static void amdgpu_userptr_test(void)
> >>>r = amdgpu_cs_ctx_free(context_handle);
> >>>CU_ASSERT_EQUAL(r, 0);
> >>>
> >>> +#ifdef HAVE_FORK
> >>>wait(NULL);
> >>> +#endif
> >>>}
> >>>
> >>>static void amdgpu_sync_dependency_test(void)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/9] drm/bridge: tc358767: Simplify polling in tc_link_training()

[Andrey Smirnov]

On Mon, Mar 4, 2019 at 4:30 AM Laurent Pinchart
 wrote:
>
> Hi Andrey,
>
> Thank you for the patch.
>
> On Tue, Feb 26, 2019 at 11:36:05AM -0800, Andrey Smirnov wrote:
> > Replace explicit polling in tc_link_training() with equivalent call to
> > regmap_read_poll_timeout() for simplicity. No functional change
> > intended (not including slightly altered debug output).
> >
> > Signed-off-by: Andrey Smirnov 
> > Cc: Archit Taneja 
> > Cc: Andrzej Hajda 
> > Cc: Laurent Pinchart 
> > Cc: Chris Healy 
> > Cc: Lucas Stach 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-ker...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/bridge/tc358767.c | 14 +-
> >  1 file changed, 5 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> > b/drivers/gpu/drm/bridge/tc358767.c
> > index 6455e6484722..ea30cec4a0c3 100644
> > --- a/drivers/gpu/drm/bridge/tc358767.c
> > +++ b/drivers/gpu/drm/bridge/tc358767.c
> > @@ -735,7 +735,6 @@ static int tc_link_training(struct tc_data *tc, int 
> > pattern)
> >   const char * const *errors;
> >   u32 srcctrl = tc_srcctrl(tc) | DP0_SRCCTRL_SCRMBLDIS |
> > DP0_SRCCTRL_AUTOCORRECT;
> > - int timeout;
> >   int retry;
> >   u32 value;
> >   int ret;
> > @@ -765,20 +764,17 @@ static int tc_link_training(struct tc_data *tc, int 
> > pattern)
> >   tc_write(DP0CTL, DP_EN);
> >
> >   /* wait */
> > - timeout = 1000;
> > - do {
> > - tc_read(DP0_LTSTAT, &value);
> > - udelay(1);
> > - } while ((!(value & LT_LOOPDONE)) && (--timeout));
> > - if (timeout == 0) {
> > + ret = regmap_read_poll_timeout(tc->regmap, DP0_LTSTAT, value,
> > +value & LT_LOOPDONE, 1, 1000);
> > + if (ret) {
> >   dev_err(tc->dev, "Link training timeout!\n");
> >   } else {
> >   int pattern = (value >> 11) & 0x3;
> >   int error = (value >> 8) & 0x7;
> >
> >   dev_dbg(tc->dev,
> > - "Link training phase %d done after %d uS: 
> > %s\n",
> > - pattern, 1000 - timeout, errors[error]);
> > + "Link training phase %d done: %s\n",
> > + pattern, errors[error]);
>
> It's probably not a big deal in this specific case, but in general it
> can be useful to know how long the poll took.

I don't disagree, but bear in mind that the way time is measured in
original loop assumes that tc_read, an I2C transaction over 100KHz
bus, takes insignificant amount of time compared to 1 uS delay. I
think original debug statement does a bit of a false advertising when
it presents a number of polling loop iterations as if it is time it
took to establish a link in microseconds.

> Any hope to enhance regmap_read_poll_timeout() to return either the elapsed 
> time or the
> remaining timeout instead of 0 on success ?
>

I'd rather not go there. That'll take convincing Mark Brown to accept
that semantics change, then fixing all of the callers across the tree
via a separate patch series.

What if instead we just add an extra debug statement before link
training starts, so that duration of the process can be discerned from
logging timestamps? This does require user doing a bit of math by
hand, but it's actually more accurate timing info compared to original
and it doesn't require any API modification.

Thanks,
Andrey Smirnov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING in vkms_vblank_simulate

[syzbot]

syzbot has bisected this bug to:

commit 09ef09b4ab95dc405ad4171ec2cd8a4ff5227108
Author: Shayenne Moura 
Date:   Wed Feb 6 20:08:13 2019 +

drm/vkms: WARN when hrtimer_forward_now fails

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=128448cf20
start commit:   09ef09b4 drm/vkms: WARN when hrtimer_forward_now fails
git tree:   upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=118448cf20
console output: https://syzkaller.appspot.com/x/log.txt?x=168448cf20
kernel config:  https://syzkaller.appspot.com/x/.config?x=c1e0e0ec44d1e5ff
dashboard link: https://syzkaller.appspot.com/bug?extid=0871b14ca2e2fb64f6e3
userspace arch: amd64
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1787db8d20
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17fc988320

Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
Fixes: 09ef09b4 ("drm/vkms: WARN when hrtimer_forward_now fails")
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/9] drm/bridge: tc358767: Simplify tc_stream_clock_calc()

[Andrey Smirnov]

On Mon, Mar 4, 2019 at 4:20 AM Laurent Pinchart
 wrote:
>
> Hello,
>
> On Mon, Mar 04, 2019 at 10:42:20AM +0100, Andrzej Hajda wrote:
> > On 26.02.2019 20:36, Andrey Smirnov wrote:
> > > Drop the use of tc_write() as well as "magicly" used "ret" and "err:"
> > > and replace it with a simple call to regmap_write(). No functional
> > > change intended.
> > >
> > > Signed-off-by: Andrey Smirnov 
> > > Cc: Archit Taneja 
> > > Cc: Andrzej Hajda 
> > > Cc: Laurent Pinchart 
> > > Cc: Chris Healy 
> > > Cc: Lucas Stach 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: linux-ker...@vger.kernel.org
> > > ---
> > >  drivers/gpu/drm/bridge/tc358767.c | 7 +--
> > >  1 file changed, 1 insertion(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> > > b/drivers/gpu/drm/bridge/tc358767.c
> > > index b0f8264a1285..86ebd49194b7 100644
> > > --- a/drivers/gpu/drm/bridge/tc358767.c
> > > +++ b/drivers/gpu/drm/bridge/tc358767.c
> > > @@ -504,7 +504,6 @@ static int tc_pxl_pll_dis(struct tc_data *tc)
> > >
> > >  static int tc_stream_clock_calc(struct tc_data *tc)
> > >  {
> > > -   int ret;
> > > /*
> > >  * If the Stream clock and Link Symbol clock are
> > >  * asynchronous with each other, the value of M changes over
> > > @@ -520,11 +519,7 @@ static int tc_stream_clock_calc(struct tc_data *tc)
> > >  * M/N = f_STRMCLK / f_LSCLK
> > >  *
> > >  */
> > > -   tc_write(DP0_VIDMNGEN1, 32768);
> > > -
> > > -   return 0;
> > > -err:
> > > -   return ret;
> > > +   return regmap_write(tc->regmap, DP0_VIDMNGEN1, 32768);
> >
> >
> > The patch looks semantically correct, but you are dropping here custom
> > accessor (tc_write) in favor of regmap API.
> >
> > I think the best would be consistent across the whole driver: either use
> > only  accessors, either drop them entirely and use regmap API.
>
> I agree with this. The tc_write macro with its goto err is pretty nasty,
> and I'd like to see it removed from the whole driver, or at least
> replaced with an accessor that wouldn't hide the goto.
>
> > And it would be good to have comment of the original authors about this
> > change.
> >

OK, I'll create a patch to remove tc_write/read in v2 and add original
authors to CC.

Thanks,
Andrey Smirnov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM-based Oops viewer

[Ahmed S. Darwish]

On Mon, Mar 11, 2019 at 02:49:41PM +0100, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 11:04:19AM +0200, Jani Nikula wrote:
> > On Sun, 10 Mar 2019, "Ahmed S. Darwish"  wrote:
> > > Hello DRM/UEFI maintainers,
> > >
> > > Several years ago, I wrote a set of patches to dump the kernel
> > > log to disk upon panic -- through BIOS INT 0x13 services. [1]
> > >
> > > The overwhelming response was that it's unsafe to do this in a
> > > generic manner. Linus proposed a video-based viewer instead: [2]
> > >
> > > If you want to do the BIOS services thing, do it for video: copy the
> > > oops to low RAM, return to real mode, re-run the graphics card POST
> > > routines to initialize text-mode, and use the BIOS to print out the
> > > oops.  That is WAY less scary than writing to disk.
> > >
> > > Of course it's 2019 now though, and it's quite known that
> > > Intel is officially obsoleting the PC/AT BIOS by 2020.. [3]
> > >
> > > Researching whether this can be done from UEFI, it was also clear
> > > that UEFI "Runtime Services" do not provide any re-initialization
> > > routines. [4]
> > >
> > > The maximum possible that UEFI can provide is a GOP-provided
> > > framebuffer that's ready to use by the OS -- even after the UEFI
> > > boot phase is marked as done through ExitBootServices(). [5]
> > >
> > > Of course, once native drivers like i915 or radeon take over,
> > > such a framebuffer is toast... [6]
> > >
> > > Thus a possible remaining option, is to display the oops through
> > > "minimal" DRM drivers provided for each HW variant... Since
> > > these special drivers will run only and fully under a panic()
> > > context though, several constraints exist:
> > >
> > >   - The code should be fully synchronous (irqs are disabled)
> > >   - It should not allocate any dynamic memory
> > >   - It should make minimal assumptions about HW state
> > >   - It should not chain into any other kernel subsystem
> > >   - It has ample freedom to use delay-based loops and the
> > > like, the kernel is already dead.
> > >
> > > How feasible is it to have such a special "DRM viewoops"
> > > framework + its minimal drivers in the kernel?
> >
> > Please first better define what you want to achieve.
> >
> > Do you want to store the dmesg or oops (like your original series
> > suggests) or do you want to display the oops? Do you want the facility
> > to be functioning at all times, or only when specifically requested in
> > advance by the user? If you want to display the oops, do you want it to
> > also work when the display is disabled at the time of the oops? What if
> > the display is at attached to a port on a dock?
> >
> > There's at least kdump, ramoops, and netconsole that can be used to
> > achieve some of what you want. How do they fall short for you?
>
> Assuming the use-case is to get an oops to display on a kms driver, we do
> have a fairly comprehensive plan of what that's should look like:
>
> https://dri.freedesktop.org/docs/drm/gpu/todo.html#make-panic-handling-work
>
> This takes into account all the failed previous attempts at trying to get
> an oops to display. It's conceptually a match with your viewoops framework
> I think.

Thanks a lot Daniel for the reference! Yup, this is a conceptual
match indeed!

It's great to know that at the maintainer level there is some
agreement on, awareness of, and plans for, the general topic...

I'll jump to Noralf Trønnes's just-posted patches then and see how
to move from there :)

all the best,

--darwi
http://darwish.chasingpointers.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING in vkms_vblank_simulate

[syzbot]

syzbot has bisected this bug to:

commit 09ef09b4ab95dc405ad4171ec2cd8a4ff5227108
Author: Shayenne Moura 
Date:   Wed Feb 6 20:08:13 2019 +

drm/vkms: WARN when hrtimer_forward_now fails

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=128448cf20
start commit:   09ef09b4 drm/vkms: WARN when hrtimer_forward_now fails
git tree:   upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=118448cf20
console output: https://syzkaller.appspot.com/x/log.txt?x=168448cf20
kernel config:  https://syzkaller.appspot.com/x/.config?x=c1e0e0ec44d1e5ff
dashboard link: https://syzkaller.appspot.com/bug?extid=0871b14ca2e2fb64f6e3
userspace arch: amd64
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1787db8d20
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17fc988320

Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
Fixes: 09ef09b4 ("drm/vkms: WARN when hrtimer_forward_now fails")
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/meson: handle when meson_canvas_get returns -EPROBE_DEFER

[Maxime Jourdan]

Hi Neil,
On Mon, Feb 4, 2019 at 10:55 AM Neil Armstrong  wrote:
>
> When meson_canvas is not yet probed, meson_canvas_get returns -EPROBE_DEFER.
>
> Handle this case but deferring the probe of the drm driver aswell.
>
> Fixes: 66cae477c380 ("drm/meson: Use optional canvas provider")
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/meson/meson_drv.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index ef4afaadaf8d..17e55d63daff 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -236,6 +236,9 @@ static int meson_drv_bind_master(struct device *dev, bool 
> has_components)
> meson_canvas_free(priv->canvas, 
> priv->canvas_id_vd1_1);
> goto free_drm;
> }
> +   } else if (PTR_ERR(priv->canvas) == -EPROBE_DEFER) {
> +   ret = PTR_ERR(priv->canvas);
> +   goto free_drm;
> } else {
> priv->canvas = NULL;
>
> --
> 2.20.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

With the upcoming patch series that aims at removing the DMC register
range from the DRM driver's control, this fix will be incorporated,
although rewritten because of code modifications in this partilcular
area.

Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM-based Oops viewer

[Ahmed S. Darwish]

Hello Jani,

On Mon, Mar 11, 2019 at 11:04:19AM +0200, Jani Nikula wrote:
> On Sun, 10 Mar 2019, "Ahmed S. Darwish"  wrote:
> > Hello DRM/UEFI maintainers,
> >
> > Several years ago, I wrote a set of patches to dump the kernel
> > log to disk upon panic -- through BIOS INT 0x13 services. [1]
> >
> > The overwhelming response was that it's unsafe to do this in a
> > generic manner. Linus proposed a video-based viewer instead: [2]
> >
> > If you want to do the BIOS services thing, do it for video: copy the
> > oops to low RAM, return to real mode, re-run the graphics card POST
> > routines to initialize text-mode, and use the BIOS to print out the
> > oops.  That is WAY less scary than writing to disk.
> >
> > Of course it's 2019 now though, and it's quite known that
> > Intel is officially obsoleting the PC/AT BIOS by 2020.. [3]
> >
> > Researching whether this can be done from UEFI, it was also clear
> > that UEFI "Runtime Services" do not provide any re-initialization
> > routines. [4]
> >
> > The maximum possible that UEFI can provide is a GOP-provided
> > framebuffer that's ready to use by the OS -- even after the UEFI
> > boot phase is marked as done through ExitBootServices(). [5]
> >
> > Of course, once native drivers like i915 or radeon take over,
> > such a framebuffer is toast... [6]
> >
> > Thus a possible remaining option, is to display the oops through
> > "minimal" DRM drivers provided for each HW variant... Since
> > these special drivers will run only and fully under a panic()
> > context though, several constraints exist:
> >
> >   - The code should be fully synchronous (irqs are disabled)
> >   - It should not allocate any dynamic memory
> >   - It should make minimal assumptions about HW state
> >   - It should not chain into any other kernel subsystem
> >   - It has ample freedom to use delay-based loops and the
> > like, the kernel is already dead.
> >
> > How feasible is it to have such a special "DRM viewoops"
> > framework + its minimal drivers in the kernel?
>
> Please first better define what you want to achieve.
>

Oh I thought this was clear..

What I want to achieve is:

  - for normal day-to-day x86 laptops users
  - properly inform the user when a kernel panic happens during
a running graphical session (e.g. wayland/gnome/kde/...).

The current situation is dismal: the screen _just freezes_, and
users are left wondering what the heck has really happened to
their system (?)

Some out-of-the-box notification mechanism, for everyday distros
like Fedora and Ubuntu that can be enabled by default, would
improve the situation considerably..

Yes, there are many _developer_ features that can mitigate the
issue somewhat, but they're not really useful for everyday "normal"
usage:

  - netconsole is definitely not an option. It implies a lab
setting where two machines are always connected through a
network.

  - ramoops is _completely irrelevant_ for normal users. It's
mostly for embedded systems and the like; requires intimate
knowledge of the hardware by the user translated into DT
bindings or special platform_data struct..

  - kexec/kdump partially solves the save-to-disk problem, but
doesn't solve the user notification part..

Maybe a new "kexec/kview" solution can be useful, but
distributions don't enable kexec/k* solutions _by default_.

Maybe they fear the extra burden of maintaining two kernels
at the same time? or the requirement of reserving memory
for the crashkernel beforehand?

Linux should not just "freeze the screen" upon panic, even
if a crashkernel is not present .. _some_ sane default
built-in user notification mechanism should be there.

  - efivars are neat, they partially solve the save-to-disk
problem, but does not solve the user notification problem.

Moreover, they always carry the risk of bricking laptops..

> Do you want to store the dmesg or oops (like your original series
> suggests) or do you want to display the oops?

The original save-to-disk series was only shown for context.
This is a pure display solution; no disk is invovled at all.

> Do you want the facility to be functioning at all times, or only
> when specifically requested in advance by the user?

At all times, as a basic "sane default" for laptop-oriented
distributions to enable (think ubuntu, fedora, mint, etc.)

> If you want to display the oops, do you want it to
> also work when the display is disabled at the time of the oops?

If the screen is disabled, then this is definitely out of scope.

This only deals with classical laptop usage scenarios, where we
want to notify the user that something went wrong at the kernel
level.

> the display is at attached to a port on a dock?
>

This is a much bigger scope that's not important at this stage.

If I'm attaching my laptop to a projector and the kernel panics,
notifying the user only in the main laptop screen should be
enough.

> There's at least kdump, ramoop

Re: [PATCH libdrm] amdgpu/basic_tests.c: check for fork

[Fabrice Fontaine]

OK, then will you accept a patch that disable amdgpu test if fork is
not available or a patch that disable all tests (for example through a
--disable-test-programs option)? Currently, the user can only disable
the cairo tests so the whole libdrm package fails to statically build
with uclibc-ng on ARM cortex M4
(http://autobuild.buildroot.org/?reason=libdrm-2.4.97).

Best Regards,

Fabrice

Le lun. 11 mars 2019 à 17:40, Christian König
 a écrit :
>
> Well NAK, cause that obviously would break the test if fork() isn't
> available.
>
> We certainly don't have any platform where we support amdgpu and fork()
> is not available, so that change is rather pointless in the first place.
>
> Christian.
>
> Am 10.03.19 um 10:44 schrieb Fabrice Fontaine:
> > amdgpu test program use fork since
> > https://cgit.freedesktop.org/mesa/drm/commit/tests/amdgpu/basic_tests.c?id=736ef0b61cab55378202c5f49d91799cc2b99091
> >
> > However, this function is not always available so add a check for it in
> > configure.ac and use it in tests/amdgpu/basic_tests.c
> >
> > Fixes:
> >   - 
> > http://autobuild.buildroot.org/results/8d6194982c1080e173fcef8212fb06e6dc275d58
> >
> > Signed-off-by: Fabrice Fontaine 
> > ---
> >   configure.ac   | 2 ++
> >   tests/amdgpu/basic_tests.c | 4 
> >   2 files changed, 6 insertions(+)
> >
> > diff --git a/configure.ac b/configure.ac
> > index d72e84ad..6effb9a2 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -193,6 +193,8 @@ AC_CHECK_FUNCS([open_memstream],
> >  [AC_DEFINE([HAVE_OPEN_MEMSTREAM], 1, [Have 
> > open_memstream()])],
> >  [AC_DEFINE([HAVE_OPEN_MEMSTREAM], 0)])
> >
> > +AC_CHECK_FUNCS([fork])
> > +
> >   dnl Use lots of warning flags with with gcc and compatible compilers
> >
> >   dnl Note: if you change the following variable, the cache is automatically
> > diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> > index dbae4d53..c32a1351 100644
> > --- a/tests/amdgpu/basic_tests.c
> > +++ b/tests/amdgpu/basic_tests.c
> > @@ -1646,10 +1646,12 @@ static void amdgpu_userptr_test(void)
> >   while (j++ < sdma_write_length)
> >   pm4[i++] = 0xdeadbeaf;
> >
> > +#ifdef HAVE_FORK
> >   if (!fork()) {
> >   pm4[0] = 0x0;
> >   exit(0);
> >   }
> > +#endif
> >
> >   amdgpu_test_exec_cs_helper(context_handle,
> >  AMDGPU_HW_IP_DMA, 0,
> > @@ -1675,7 +1677,9 @@ static void amdgpu_userptr_test(void)
> >   r = amdgpu_cs_ctx_free(context_handle);
> >   CU_ASSERT_EQUAL(r, 0);
> >
> > +#ifdef HAVE_FORK
> >   wait(NULL);
> > +#endif
> >   }
> >
> >   static void amdgpu_sync_dependency_test(void)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/sun4i: hdmi: add support for ddc-i2c-bus property

[Måns Rullgård]

Maxime Ripard  writes:

> Hi!
>
> On Mon, Mar 11, 2019 at 01:47:13PM +, Mans Rullgard wrote:
>> Sometimes it is desirabled to use a separate i2c controller for ddc
>> access.  This adds support for the ddc-i2c-bus property of the
>> hdmi-connector node, using the specified controller if provided.
>> 
>> Signed-off-by: Mans Rullgard 
>> ---
>>  drivers/gpu/drm/sun4i/sun4i_hdmi.h |  1 +
>>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 37 +++---
>>  2 files changed, 35 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
>> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
>> index b685ee11623d..b08c4453d47c 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
>> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
>> @@ -269,6 +269,7 @@ struct sun4i_hdmi {
>>  struct clk  *tmds_clk;
>>  
>>  struct i2c_adapter  *i2c;
>> +struct i2c_adapter  *ddc_i2c;
>>  
>>  /* Regmap fields for I2C adapter */
>>  struct regmap_field *field_ddc_en;
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
>> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
>> index 061d2e0d9011..5b2fac79f5d6 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
>> @@ -212,7 +212,7 @@ static int sun4i_hdmi_get_modes(struct drm_connector 
>> *connector)
>>  struct edid *edid;
>>  int ret;
>>  
>> -edid = drm_get_edid(connector, hdmi->i2c);
>> +edid = drm_get_edid(connector, hdmi->ddc_i2c ?: hdmi->i2c);
>
> You can't test whether ddc_i2c is NULL or not...
>
>>  if (!edid)
>>  return 0;
>>  
>> @@ -228,6 +228,28 @@ static int sun4i_hdmi_get_modes(struct drm_connector 
>> *connector)
>>  return ret;
>>  }
>>  
>> +static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device *dev)
>> +{
>> +struct device_node *phandle, *remote;
>> +struct i2c_adapter *ddc;
>> +
>> +remote = of_graph_get_remote_node(dev->of_node, 1, -1);
>> +if (!remote)
>> +return ERR_PTR(-EINVAL);
>> +
>> +phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
>> +of_node_put(remote);
>> +if (!phandle)
>> +return NULL;
>> +
>> +ddc = of_get_i2c_adapter_by_node(phandle);
>> +of_node_put(phandle);
>> +if (!ddc)
>> +return ERR_PTR(-EPROBE_DEFER);
>> +
>> +return ddc;
>
> ... Since even in (most) error cases you're returning a !NULL pointer.
>
>> +}
>> +
>>  static const struct drm_connector_helper_funcs 
>> sun4i_hdmi_connector_helper_funcs = {
>>  .get_modes  = sun4i_hdmi_get_modes,
>>  };
>> @@ -575,6 +597,12 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
>> device *master,
>>  goto err_disable_mod_clk;
>>  }
>>  
>> +hdmi->ddc_i2c = sun4i_hdmi_get_ddc(dev);
>> +if (IS_ERR(hdmi->ddc_i2c)) {

... which is checked here.

The property is optional, so the idea was to return null in that case
and use the built-in controller.  If the property exists but some error
occurs, we want to abort rather than proceed with the fallback which
almost certainly won't work.

Maybe I got something wrong in that logic.

-- 
Måns Rullgård
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [5.2][PATCH 0/3] Ingenic JZ47xx KMS driver

[Paul Cercueil]

Hi Ezequiel,

On Mon, Mar 11, 2019 at 1:02 AM, Ezequiel Garcia 
 wrote:

On Thu, 2019-02-28 at 19:07 -0300, Paul Cercueil wrote:

 Hi,

 This is a first attempt at a KMS driver for the JZ47xx MIPS SoCs by
 Ingenic. It is aimed to replace the aging jz4740-fb driver.

 The driver will later be updated with new features (overlays, TV-out
 etc.), that's why I didn't go with the simple/tiny DRM driver.

 The driver has been tested on the Ben Nanonote (JZ4740) and the
 RetroMini RS-90 (JZ4725B) handheld gaming console.



Does this support JZ4780? Or otherwise,
is there any similarity with JZ4780 display controller?

Thanks,
Eze


The JZ4780 LCD controller would in theory work with this driver, but
to test on the CI20 you'd need to add support for HDMI first.

-Paul


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/9] drm/bridge: tc358767: Simplify error check in tc_aux_linx_setup()

[Andrey Smirnov]

On Mon, Mar 4, 2019 at 4:33 AM Laurent Pinchart
 wrote:
>
> Hi Andrey,
>
> Thank you for the patch.
>
> On Tue, Feb 26, 2019 at 11:36:06AM -0800, Andrey Smirnov wrote:
> > Tc_poll_timeout() can only return -ETIMEDOUT, so checking for other
> > errors is not necessary. Drop it. No functional change intended.
>
> Is that true given patch 1/9 in this series ? regmap_read_poll_timeout()
> can also return an error from regmap_read().
>

Ugh, I misread "?:" in regmap_read_poll_timeout() code as "?", this
patch is incorrect. Sorry about that, will drop in v2.

Thanks,
Andrey Smirnov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: INFO: rcu detected stall in sys_sendfile64 (2)

[syzbot]

syzbot has bisected this bug to:

commit 34e07e42c55aeaa78e93b057a6664e2ecde3fadb
Author: Chris Wilson 
Date:   Thu Feb 8 10:54:48 2018 +

drm/i915: Add missing kerneldoc for 'ent' in i915_driver_init_early

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1322028320
start commit:   34e07e42 drm/i915: Add missing kerneldoc for 'ent' in i915..
git tree:   upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=10a2028320
console output: https://syzkaller.appspot.com/x/log.txt?x=1722028320
kernel config:  https://syzkaller.appspot.com/x/.config?x=abc3dc9b7a900258
dashboard link: https://syzkaller.appspot.com/bug?extid=1505c80c74256c6118a5
userspace arch: amd64
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=12c4dc28c0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15df4108c0

Reported-by: syzbot+1505c80c74256c611...@syzkaller.appspotmail.com
Fixes: 34e07e42 ("drm/i915: Add missing kerneldoc for 'ent' in  
i915_driver_init_early")

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] FBTFT: fbtft-bus: Fix code style problems

[DANTE JAVIER PAZ]

Hi Dan,
Thanks a lot for your feedback, this is my first patch for the linux kernel
so I'm learning a lot from your comments.

I'll try to make a more clear version of the patch following your
suggestions
to resubmit.

Best,
Dante Paz

El lun., 11 mar. 2019 a las 5:18, Dan Carpenter ()
escribió:

> I feel like you need to break the patch up a bit and do the white
> space fixes separate from the other changes.
>
> (Probably you're going to have to redo this several times because it's
> hard to review when it's so mixed up with multiple changes at the same
> time).
>
> regards,
> dan carpenter
>
>

-- 
-- 
Dr. Dante Javier Paz
Instituto de Astronomía, Teórica y Experimental, IATE
Observatorio Astronómico de Córdoba

Tel: (54) 351-5353776 ext 75643
Web: www.iate.oac.uncor.edu


Laprida 854
X5000BGR - Córdoba
ARGENTINA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Is it possible to reset graphics controller on reboot in a framebuffer driver?

[Tom Li]

On Fri, Mar 08, 2019 at 06:35:36PM +0800, Tom Li wrote:
> On Fri, Mar 08, 2019 at 10:13:58AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Mar 7, 2019 at 10:38 PM Tom Li  wrote:
> > > Nevertheless, does it mean there's no way to prevent it from happening if 
> > > the
> > > user issues a emergency reboot? Like an automatic reboot after a kernel 
> > > panic,
> > > or a SysRq-B reboot.
> > 
> > If Linux performs a reboot, it calls the shutdown handlers.
> > I think that includes reboot on panic, or SysRq-B, but I'd have to check to
> > be 100% sure.
> 
> Okay, glad to hear that. If it works for SysRq-B or panic reboot, I think
> it would be enough. After all, hard kernel crashes are rare nowadays, and
> most crashes are hard lockups. In case it happens, the user just presses
> the power button to halt.

As I suspected, emergency reboot via SysRq-B is a hard reboot and none of the
reboot handler will be called. I've put a for (;;) {} loop in .shutdown(), the
kernel would hang during a normal reboot, but a SysRq-B reboot will reset the
machine immediately.

Fortunately, I've found a way to stop trigger the bug in the driver, so no
shutdown handler is needed anymore.

Cheers,
Tom Li
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] [v6,2/2] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel

[Jerry Han]

Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
panel.

V6:
- Add the information of the reviewer (Sam)
- Delete unnecessary header files #include  (Sam)
- The config DRM_PANEL_BOE_HIMAX8279D appears twice. Drop one of them (Sam)
- ADD static, set_gpios function is not used outside this module (Sam)

v5:
- Added changelog

v4:
- Frefix all function maes with boe_ (Sam)
- Fsed "enable_gpio" replace "reset_gpio", Make it look clearer (Sam)
- Sort include lines alphabetically (Sam)
- Fixed entries in the makefile must be sorted alphabetically (Sam)
- Add send_mipi_cmds function to avoid duplicating the code (Sam)
- Add the necessary delay(reset_delay_t5) between reset and sending
the initialization command (Rock wang)

v3:
- Remove unnecessary delays in sending initialization commands (Jitao Shi)

V2:
- Use SPDX identifier (Sam)
- Use necessary header files replace drmP.h (Sam)
- Delete unnecessary header files #include  (Sam)
- Specifies a GPIOs array to control the reset timing,
instead of reading "dsi-reset-sequence" data from DTS (Sam)
- Delete backlight_disable() function when already disabled (Sam)
- Use devm_of_find_backlight() replace of_find_backlight_by_node() (Sam)
- Move the necessary data in the DTS to the current file,
like porch, display_mode and Init code etc. (Sam)
- Add compatible device "boe,himax8279d10p" (Sam)

Signed-off-by: Jerry Han 
Reviewed-by: Sam Ravnborg 
Cc: Jitao Shi 
Cc: Derek Basehore 
Cc: Rock wang 
---
 MAINTAINERS  |6 +
 drivers/gpu/drm/panel/Kconfig|   11 +
 drivers/gpu/drm/panel/Makefile   |1 +
 drivers/gpu/drm/panel/panel-boe-himax8279d.c | 1069 ++
 4 files changed, 1087 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-boe-himax8279d.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b2f710e..095fbbe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4624,6 +4624,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 S: Maintained
 F: drivers/gpu/drm/bochs/
 
+DRM DRIVER FOR BOE HIMAX8279D PANELS
+M: Jerry Han 
+S: Maintained
+F: drivers/gpu/drm/panel/panel-boe-himax8279d.c
+F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
+
 DRM DRIVER FOR FARADAY TVE200 TV ENCODER
 M: Linus Walleij 
 T: git git://anongit.freedesktop.org/drm/drm-misc
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6020c30..4aae4a7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -17,6 +17,17 @@ config DRM_PANEL_ARM_VERSATILE
  reference designs. The panel is detected using special registers
  in the Versatile family syscon registers.
 
+config DRM_PANEL_BOE_HIMAX8279D
+   tristate "Boe Himax8279d panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Boe Himax8279d
+ TFT-LCD modules. The panel has a 1200x1920 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
 config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5ccaaa9..7285539 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
+obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c 
b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
new file mode 100644
index 000..c050a48
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
@@ -0,0 +1,1069 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, Huaqin Telecom Technology Co., Ltd
+ *
+ * Author: Jerry Han 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct panel_cmd {
+   size_t len;
+   const char *data;
+};
+
+#define _INIT_CMD(...) { \
+   .len = sizeof((char[]){__VA_ARGS__}), \
+   .data = (char[]){__VA_ARGS__} }
+
+struct panel_desc {
+   const struct drm_display_mode *display_mode;
+   unsigned int bpc;
+   unsigned int width_mm;
+   unsigned int height_mm;
+
+   unsigned int delay_t1;
+   unsigned int reset_delay_t2;
+   unsigned int reset_delay_t3;
+   unsigned int reset_delay_t4;
+   unsigned int reset_delay_t5;
+
+   unsigned long mode_flags;
+   enum mipi_dsi_pixel_format format;
+   unsigned int lanes;
+   

Re: [PATCH] FBTFT: fbtft-bus: Fix code style problems

[DANTE JAVIER PAZ]

Hello Sam, thank you very much for your comments,
As I told Dan (my email did not reach the mailing list) this is my
first attempt to contribute,
So I'm learning a lot from your advice and corrections.

I will look for TODO lists to see if there are more useful
contributions to make, all suggestions are also welcome.

Thanks again for the patience of all of you.
Best,
Dante


El lun., 11 mar. 2019 a las 13:25, Sam Ravnborg () escribió:
>
> Hi Dante
>
> Thanks for the patch.
> On Sat, Mar 09, 2019 at 06:48:52PM -0300, Dante Paz wrote:
> > From: Dante Paz 
> >
> > Style and coding function issues were corrected, by avoiding macro 
> > functions with a conflicting coding style.
> > Signed-off-by: Dante Paz 
>
> But it raised a few comments.
>
> The staging/fbtft is a dumping of a set of drivers that
> in the end will be migrated to DRM.
> And there is not much gained trying to do coding style changes to these
> drivers.
> So please conmsider finding a drver where this is more relevant.
>
> Furthermore that patch presented is hard to review as it contains
> too much changes in one go.
> As a rule of thumb include only one type of change per patch.
> This is worth to keep in mind for future submissions.
>
> It it then also good to present the trivial changes first(*), and the
> less trivial changes later.
>
> (*) Like whitespace to tabs, spellign errors etc.
>
> Sam



-- 
-- 
Dr. Dante Javier Paz
Instituto de Astronomía, Teórica y Experimental, IATE
Observatorio Astronómico de Córdoba

Tel: (54) 351-5353776 ext 75643
Web: www.iate.oac.uncor.edu


Laprida 854
X5000BGR - Córdoba
ARGENTINA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/sun4i: hdmi: add support for ddc-i2c-bus property

[Mans Rullgard]

Sometimes it is desirabled to use a separate i2c controller for ddc
access.  This adds support for the ddc-i2c-bus property of the
hdmi-connector node, using the specified controller if provided.

Signed-off-by: Mans Rullgard 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi.h |  1 +
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 37 +++---
 2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index b685ee11623d..b08c4453d47c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -269,6 +269,7 @@ struct sun4i_hdmi {
struct clk  *tmds_clk;
 
struct i2c_adapter  *i2c;
+   struct i2c_adapter  *ddc_i2c;
 
/* Regmap fields for I2C adapter */
struct regmap_field *field_ddc_en;
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 061d2e0d9011..5b2fac79f5d6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -212,7 +212,7 @@ static int sun4i_hdmi_get_modes(struct drm_connector 
*connector)
struct edid *edid;
int ret;
 
-   edid = drm_get_edid(connector, hdmi->i2c);
+   edid = drm_get_edid(connector, hdmi->ddc_i2c ?: hdmi->i2c);
if (!edid)
return 0;
 
@@ -228,6 +228,28 @@ static int sun4i_hdmi_get_modes(struct drm_connector 
*connector)
return ret;
 }
 
+static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device *dev)
+{
+   struct device_node *phandle, *remote;
+   struct i2c_adapter *ddc;
+
+   remote = of_graph_get_remote_node(dev->of_node, 1, -1);
+   if (!remote)
+   return ERR_PTR(-EINVAL);
+
+   phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
+   of_node_put(remote);
+   if (!phandle)
+   return NULL;
+
+   ddc = of_get_i2c_adapter_by_node(phandle);
+   of_node_put(phandle);
+   if (!ddc)
+   return ERR_PTR(-EPROBE_DEFER);
+
+   return ddc;
+}
+
 static const struct drm_connector_helper_funcs 
sun4i_hdmi_connector_helper_funcs = {
.get_modes  = sun4i_hdmi_get_modes,
 };
@@ -575,6 +597,12 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
goto err_disable_mod_clk;
}
 
+   hdmi->ddc_i2c = sun4i_hdmi_get_ddc(dev);
+   if (IS_ERR(hdmi->ddc_i2c)) {
+   ret = PTR_ERR(hdmi->ddc_i2c);
+   goto err_del_i2c_adapter;
+   }
+
drm_encoder_helper_add(&hdmi->encoder,
   &sun4i_hdmi_helper_funcs);
ret = drm_encoder_init(drm,
@@ -584,14 +612,14 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
   NULL);
if (ret) {
dev_err(dev, "Couldn't initialise the HDMI encoder\n");
-   goto err_del_i2c_adapter;
+   goto err_put_ddc_i2c;
}
 
hdmi->encoder.possible_crtcs = drm_of_find_possible_crtcs(drm,
  dev->of_node);
if (!hdmi->encoder.possible_crtcs) {
ret = -EPROBE_DEFER;
-   goto err_del_i2c_adapter;
+   goto err_put_ddc_i2c;
}
 
 #ifdef CONFIG_DRM_SUN4I_HDMI_CEC
@@ -630,6 +658,8 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
 err_cleanup_connector:
cec_delete_adapter(hdmi->cec_adap);
drm_encoder_cleanup(&hdmi->encoder);
+err_put_ddc_i2c:
+   i2c_put_adapter(hdmi->ddc_i2c);
 err_del_i2c_adapter:
i2c_del_adapter(hdmi->i2c);
 err_disable_mod_clk:
@@ -650,6 +680,7 @@ static void sun4i_hdmi_unbind(struct device *dev, struct 
device *master,
drm_connector_cleanup(&hdmi->connector);
drm_encoder_cleanup(&hdmi->encoder);
i2c_del_adapter(hdmi->i2c);
+   i2c_put_adapter(hdmi->ddc_i2c);
clk_disable_unprepare(hdmi->mod_clk);
clk_disable_unprepare(hdmi->bus_clk);
 }
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/fourcc: add ARM GPU tile format

[Alyssa Rosenzweig]

> You might want to re-use the exisiting modifier
> AFBC_FORMAT_MOD_BLOCK_SIZE_16x16.
> 
> I would suggest you to have a look at the exisiting AFBC modifiers
> (denoted by AFBC_FORMAT_MOD_XXX ) and let us know if there is
> something you cannot reuse.

So, the "tiled" format in question (that Qiang needs to import/export
BOs in) is *uncompressed* but tiled with an Arm-internal format (for the
GPUs).  Here's a software implementation for encoding this format:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/panfrost/pan_swizzle.c

For Midgard/Bifrost, we use this tiling internally for uploading bitmap
textures, but we only render to AFBC (or linear). So for Panfrost, we'll
always be importing/exporting AFBC buffers, never uncompressed tiled.
But Utgard does not seem to support AFBC (?), so Qiang needs the
uncompressed tiled for the same purpose Panfrost uses AFBC.

Is it possible that this is the same tiling used internally by
AFBC_FORMAT_MOD_BLOCK_SIZE_16x16, only without any compression? AFBC is
blackbox for us, so this isn't something we can figure out ourselves,
but that influences whether it's appropriate to reuse the modifier. If
this is the same tiling scheme, perhaps that's the answer. If it's not
(I don't know how AFBC tiling works), we probably do need a separate
modifier to avoid confusion.

Thanks,

Alyssa


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/meson: exclusively use the canvas provider module

[Maxime Jourdan]

Now that the DMC register range is no longer in the bindings, remove any
mention towards it and exclusively use the meson-canvas module.

Signed-off-by: Maxime Jourdan 
---
 drivers/gpu/drm/meson/Makefile|  2 +-
 drivers/gpu/drm/meson/meson_canvas.c  | 73 ---
 drivers/gpu/drm/meson/meson_canvas.h  | 51 
 drivers/gpu/drm/meson/meson_crtc.c| 84 ---
 drivers/gpu/drm/meson/meson_drv.c | 68 --
 drivers/gpu/drm/meson/meson_drv.h |  1 -
 drivers/gpu/drm/meson/meson_overlay.c |  8 ---
 drivers/gpu/drm/meson/meson_plane.c   |  6 +-
 drivers/gpu/drm/meson/meson_viu.c |  1 -
 9 files changed, 51 insertions(+), 243 deletions(-)
 delete mode 100644 drivers/gpu/drm/meson/meson_canvas.c
 delete mode 100644 drivers/gpu/drm/meson/meson_canvas.h

diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index 7709f2fbb9f7..d4ea82fc493b 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -1,5 +1,5 @@
 meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o meson_venc_cvbs.o
-meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o 
meson_canvas.o meson_overlay.o
+meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o 
meson_overlay.o
 
 obj-$(CONFIG_DRM_MESON) += meson-drm.o
 obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
diff --git a/drivers/gpu/drm/meson/meson_canvas.c 
b/drivers/gpu/drm/meson/meson_canvas.c
deleted file mode 100644
index 5de11aa7c775..
--- a/drivers/gpu/drm/meson/meson_canvas.c
+++ /dev/null
@@ -1,73 +0,0 @@
-/*
- * Copyright (C) 2016 BayLibre, SAS
- * Author: Neil Armstrong 
- * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
- * Copyright (C) 2014 Endless Mobile
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- */
-
-#include 
-#include 
-#include "meson_drv.h"
-#include "meson_canvas.h"
-#include "meson_registers.h"
-
-/**
- * DOC: Canvas
- *
- * CANVAS is a memory zone where physical memory frames information
- * are stored for the VIU to scanout.
- */
-
-/* DMC Registers */
-#define DMC_CAV_LUT_DATAL  0x48 /* 0x12 offset in data sheet */
-#define CANVAS_WIDTH_LBIT  29
-#define CANVAS_WIDTH_LWID   3
-#define DMC_CAV_LUT_DATAH  0x4c /* 0x13 offset in data sheet */
-#define CANVAS_WIDTH_HBIT   0
-#define CANVAS_HEIGHT_BIT   9
-#define CANVAS_BLKMODE_BIT  24
-#define CANVAS_ENDIAN_BIT  26
-#define DMC_CAV_LUT_ADDR   0x50 /* 0x14 offset in data sheet */
-#define CANVAS_LUT_WR_EN(0x2 << 8)
-#define CANVAS_LUT_RD_EN(0x1 << 8)
-
-void meson_canvas_setup(struct meson_drm *priv,
-   uint32_t canvas_index, uint32_t addr,
-   uint32_t stride, uint32_t height,
-   unsigned int wrap,
-   unsigned int blkmode,
-   unsigned int endian)
-{
-   unsigned int val;
-
-   regmap_write(priv->dmc, DMC_CAV_LUT_DATAL,
-   (((addr + 7) >> 3)) |
-   (((stride + 7) >> 3) << CANVAS_WIDTH_LBIT));
-
-   regmap_write(priv->dmc, DMC_CAV_LUT_DATAH,
-   stride + 7) >> 3) >> CANVAS_WIDTH_LWID) <<
-   CANVAS_WIDTH_HBIT) |
-   (height << CANVAS_HEIGHT_BIT) |
-   (wrap << 22) |
-   (blkmode << CANVAS_BLKMODE_BIT) |
-   (endian << CANVAS_ENDIAN_BIT));
-
-   regmap_write(priv->dmc, DMC_CAV_LUT_ADDR,
-   CANVAS_LUT_WR_EN | canvas_index);
-
-   /* Force a read-back to make sure everything is flushed. */
-   regmap_read(priv->dmc, DMC_CAV_LUT_DATAH, &val);
-}
diff --git a/drivers/gpu/drm/meson/meson_canvas.h 
b/drivers/gpu/drm/meson/meson_canvas.h
deleted file mode 100644
index 85dbf26e2826..
--- a/drivers/gpu/drm/meson/meson_canvas.h
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * Copyright (C) 2016 BayLibre, SAS
- * Author: Neil Armstrong 
- * Copyright (C) 2014 Endless Mobile
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRA

Re: [PATCH 1/5] drm: don't block fb changes for async plane updates

[Daniel Vetter]

On Tue, Mar 12, 2019 at 10:32:09AM +0100, Boris Brezillon wrote:
> On Mon, 11 Mar 2019 20:51:27 +0100
> Daniel Vetter  wrote:
> 
> > On Mon, Mar 11, 2019 at 03:20:09PM +0100, Boris Brezillon wrote:
> > > On Mon, 11 Mar 2019 13:15:23 +
> > > "Kazlauskas, Nicholas"  wrote:
> > >   
> > > > On 3/11/19 6:06 AM, Boris Brezillon wrote:  
> > > > > Hello Nicholas,
> > > > > 
> > > > > On Mon, 4 Mar 2019 15:46:49 +
> > > > > "Kazlauskas, Nicholas"  wrote:
> > > > > 
> > > > >> On 3/4/19 9:49 AM, Helen Koike wrote:
> > > > >>> In the case of a normal sync update, the preparation of 
> > > > >>> framebuffers (be
> > > > >>> it calling drm_atomic_helper_prepare_planes() or doing setups with
> > > > >>> drm_framebuffer_get()) are performed in the new_state and the 
> > > > >>> respective
> > > > >>> cleanups are performed in the old_state.
> > > > >>>
> > > > >>> In the case of async updates, the preparation is also done in the
> > > > >>> new_state but the cleanups are done in the new_state (because 
> > > > >>> updates
> > > > >>> are performed in place, i.e. in the current state).
> > > > >>>
> > > > >>> The current code blocks async udpates when the fb is changed, 
> > > > >>> turning
> > > > >>> async updates into sync updates, slowing down cursor updates and
> > > > >>> introducing regressions in igt tests with errors of type:
> > > > >>>
> > > > >>> "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
> > > > >>> expect to complete approximately 15360 updates, with the threshold 
> > > > >>> set
> > > > >>> at 7680"
> > > > >>>
> > > > >>> Fb changes in async updates were prevented to avoid the following 
> > > > >>> scenario:
> > > > >>>
> > > > >>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
> > > > >>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
> > > > >>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup 
> > > > >>> fb2 (wrong)
> > > > >>> Where we have a single call to prepare fb2 but double cleanup call 
> > > > >>> to fb2.
> > > > >>>
> > > > >>> To solve the above problems, instead of blocking async fb changes, 
> > > > >>> we
> > > > >>> place the old framebuffer in the new_state object, so when the code
> > > > >>> performs cleanups in the new_state it will cleanup the old_fb and we
> > > > >>> will have the following scenario instead:
> > > > >>>
> > > > >>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
> > > > >>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
> > > > >>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup 
> > > > >>> fb2
> > > > >>>
> > > > >>> Where calls to prepare/cleanup are ballanced.
> > > > >>>
> > > > >>> Cc:  # v4.14+: 25dc194b34dd: drm: Block fb 
> > > > >>> changes for async plane updates
> > > > >>> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane 
> > > > >>> updates")
> > > > >>> Suggested-by: Boris Brezillon 
> > > > >>> Signed-off-by: Helen Koike 
> > > > >>>
> > > > >>> ---
> > > > >>> Hello,
> > > > >>>
> > > > >>> As mentioned in the cover letter,
> > > > >>> I tested on the rockchip and on i915 (with a patch I am still 
> > > > >>> working on for
> > > > >>> replacing cursors by async update), with igt plane_cursor_legacy and
> > > > >>> kms_cursor_legacy and I didn't see any regressions.
> > > > >>> I couldn't test on MSM and AMD because I don't have the hardware 
> > > > >>> (and I am
> > > > >>> having some issues testing on vc4) and I would appreciate if anyone 
> > > > >>> could help
> > > > >>> me testing those.
> > > > >>>
> > > > >>> I also think it would be a better solution if, instead of having 
> > > > >>> async
> > > > >>> to do in-place updates in the current state, the async path should 
> > > > >>> be
> > > > >>> equivalent to a syncronous update, i.e., modifying new_state and
> > > > >>> performing a flip
> > > > >>> IMHO, the only difference between sync and async should be that 
> > > > >>> async update
> > > > >>> doesn't wait for vblank and applies the changes immeditally to the 
> > > > >>> hw,
> > > > >>> but the code path could be almost the same.
> > > > >>> But for now I think this solution is ok (swaping new_fb/old_fb), and
> > > > >>> then we can adjust things little by little, what do you think?
> > > > >>>
> > > > >>> Thanks!
> > > > >>> Helen
> > > > >>>
> > > > >>>drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
> > > > >>>1 file changed, 10 insertions(+), 10 deletions(-)
> > > > >>>
> > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > > >>> b/drivers/gpu/drm/drm_atomic_helper.c
> > > > >>> index 540a77a2ade9..e7eb96f1efc2 100644
> > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > >>> @@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct 
> > > > >>> drm_device *dev,
> > > > >>> old_plane_state->crtc != new_plane_state->crtc)
> > > > >>> retu

[Bug 109973] System hangs/freeze/hiccups

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109973

Bug ID: 109973
   Summary: System hangs/freeze/hiccups
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: FreeBSD
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: walterkrup...@gmail.com

Hi all,

My system is:
CPU: AMD Ryzen2 2700x
MB: Asus x470-F
Memory: Corsair 32GB PC3200mhz
GPU: Asus Rog Strix Vega 64
Monitor: Asus MG279Q ( 2560x1440, 144hz ) (connected at display port 0) +
(FreeSync is ON from Monitor Settings) (also tried OFF)
Disk: Corsair Nvme 1920gb
OS: Freebsd 12 p3

Problem Description: Sudden FPS dropouts and sometimes full system freeze/lock
(requires hard reset), + and time to time 15/30ms freezes (doesnt require hard
reboot but happens exactly the same time with sudden fps dropouts)

can be problem caused by dynamic power management of gpu/amdgpu ? ( i did
amdgpu.dpm=0 at /boot/loader.conf but doesnt seem to effect.. )

Note: all the hardware above has been tested at another pc, they work
flawlessly at arch linux (no freezes no hiccups no sudden fps dropouts) (so
hardware are fine)

clinfo reports;
Number of platforms 0

.. so I'm confused about what works and not or partially works in my system..
(opengl,opencl,vulkan,rocm?,etc..) (+which packages/ports are missing and need
to be installed..)

Attached files are: (due attachment limit per post were 5 files max, i posted
the rest of the files with my other posts in this topic)
1> uname -a
2> kldstat
3> xrandr
4> /boot/loader.conf
5> /etc/rc.conf
6> dmesg
7> /var/log/messages
8> xorg.conf
9> /var/log/xorg.log.0
10> /var/log/Xorg.log.0 (when full system freeze occurs)=> "[mi] EQ
overflowing." + "[mi] This may be caused by a misbehaving driver monopolizing
the server's resources."
11> pkg info (installed packages) (comparison with arch wiki amdgpu + xorg
amdgpu + https://wiki.freebsd.org/Graphics)
12/13/14/15> glxinfo + glxgears + vulkaninfo + vdpauinfo
16> pciconf -lvbce
17> devinfo -vr
18> sysctl hw.model
---> total 18 files.

Since I cant attach all the files above to this bug report, i submit the
link/url that I have attached them to.. 

https://forums.freebsd.org/threads/freebsd-12-amdgpu-freeze-hiccups.69980/

I really would appriciate any help. 
Thanks again

-- 
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 v2 1/3] drm: Add support for panic message output

[Daniel Vetter]

On Mon, Mar 11, 2019 at 11:40:36PM +0100, Noralf Trønnes wrote:
> 
> 
> Den 11.03.2019 20.29, skrev Daniel Vetter:
> > On Mon, Mar 11, 2019 at 08:23:38PM +0100, Daniel Vetter wrote:
> >> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> >>> This adds support for outputting kernel messages on panic().
> >>> A kernel message dumper is used to dump the log. The dumper iterates
> >>> over each DRM device and it's crtc's to find suitable framebuffers.
> >>>
> >>> All the other dumpers are run before this one except mtdoops.
> >>> Only atomic drivers are supported.
> >>>
> >>> Signed-off-by: Noralf Trønnes 
> 
> 
> 
> >>> +static void drm_panic_try_dev(struct drm_device *dev, struct kmsg_dumper 
> >>> *dumper)
> >>> +{
> >>> + struct drm_framebuffer *fb;
> >>> + struct drm_plane *plane;
> >>> + struct drm_crtc *crtc;
> >>> +
> >>> + if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> >>> + return;
> >>> +
> >>> + if (dumper->max_reason == KMSG_DUMP_OOPS)
> >>> + pr_info("%s: %s on minor %d\n", __func__, dev->driver->name,
> >>> + dev->primary->index);
> >>> +
> >>> + drm_for_each_crtc(crtc, dev) {
> >>> + if (!ww_mutex_trylock(&crtc->mutex.mutex))
> >>> + continue;
> >>> +
> >>> + if (!crtc->enabled || !crtc->primary)
> >>> + goto crtc_unlock;
> >>> +
> >>> + if (!crtc->state || !crtc->state->active)
> >>> + goto crtc_unlock;
> >>> +
> >>> + plane = crtc->primary;
> >>> + if (!ww_mutex_trylock(&plane->mutex.mutex))
> >>> + goto crtc_unlock;
> >>> +
> >>> + /*
> >>> +  * TODO: Should we check plane_state->visible?
> >>> +  * It is not set on vc4
> >>
> >> I think we should. We should also check whether that primary is connected
> >> to the crtc (some hw you can reassign planes freely between crtc, and the
> >> crtc->primary pointer is only used for compat with legacy ioctl).
> >>
> >>> + if (!plane->state || !plane->state->visible)
> >>> +  */
> >>> + if (!plane->state)
> >>> + goto plane_unlock;
> >>> +
> >>> + fb = plane->state->fb;
> >>> + if (!fb || !fb->funcs->panic_vmap)
> >>
> >> Docs says this is optional, doesn't seem to be all that optional. I'd
> >> check for this or a driver-specific ->panic_draw_xy instead.
> >>> + goto plane_unlock;
> >>> +
> >>> + /*
> >>> +  * fbcon puts out panic messages so stay away to avoid jumbled
> >>> +  * output. If vc->vc_mode != KD_TEXT fbcon won't put out
> >>> +  * messages (see vt_console_print).
> >>> +  */
> >>> + if (dev->fb_helper && dev->fb_helper->fb == fb)
> > 
> > This is a bit a layering violation. Could we instead tell fbcon that it
> > shouldn't do panic handling for drm drivers? I think that would resolve
> > this overlap here in a much cleaner way. drm fbdev helpers already have
> > lots of oops_in_progress checks all over to make sure fbcon doesn't do
> > anything bad. That only leaves the actual rendering, which I think we can
> > stop too with a simple flag.
> > 
> > Ofc only for atomic drivers which have this panic handling mode here
> > implemented.
> 
> There used to be a fbdev flag FBINFO_CAN_FORCE_OUTPUT that controlled
> vc->vc_panic_force_write, but it's gone now I see.

I killed that :-)

Looking at those patches again, it's not what we wanted. It was used to
force panic display even when not in KD_TEXT mode.

What we want instead here is a flag to tell fbcon/vt to _never_ write
dmesg to our console, not even when the console is in KD_TEXT mode.
Because we have a separate panic handler to display it. Heck maybe that QR
code thing could be resurrected eventually again.

Totally untested snippet below is what I'm thinking of:


diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 7f4c22a65f63..b08c63286ed0 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -282,6 +282,9 @@ static inline int fbcon_is_inactive(struct vc_data *vc, 
struct fb_info *info)
 {
struct fbcon_ops *ops = info->fbcon_par;
 
+   if (oops_in_progress && info->flags & NO_OOPS_OUTPUT)
+   return false;
+
return (info->state != FBINFO_STATE_RUNNING ||
vc->vc_mode != KD_TEXT || ops->graphics);
 }


Plus then unconditionally rendering the oops output on the drm side, even
if the current fb is the fbcon one.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] drm: Add support for panic message output

[Daniel Vetter]

On Tue, Mar 12, 2019 at 10:53:20AM +0100, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 11:40:36PM +0100, Noralf Trønnes wrote:
> > 
> > 
> > Den 11.03.2019 20.29, skrev Daniel Vetter:
> > > On Mon, Mar 11, 2019 at 08:23:38PM +0100, Daniel Vetter wrote:
> > >> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> > >>> This adds support for outputting kernel messages on panic().
> > >>> A kernel message dumper is used to dump the log. The dumper iterates
> > >>> over each DRM device and it's crtc's to find suitable framebuffers.
> > >>>
> > >>> All the other dumpers are run before this one except mtdoops.
> > >>> Only atomic drivers are supported.
> > >>>
> > >>> Signed-off-by: Noralf Trønnes 
> > 
> > 
> > 
> > >>> +static void drm_panic_try_dev(struct drm_device *dev, struct 
> > >>> kmsg_dumper *dumper)
> > >>> +{
> > >>> +   struct drm_framebuffer *fb;
> > >>> +   struct drm_plane *plane;
> > >>> +   struct drm_crtc *crtc;
> > >>> +
> > >>> +   if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> > >>> +   return;
> > >>> +
> > >>> +   if (dumper->max_reason == KMSG_DUMP_OOPS)
> > >>> +   pr_info("%s: %s on minor %d\n", __func__, 
> > >>> dev->driver->name,
> > >>> +   dev->primary->index);
> > >>> +
> > >>> +   drm_for_each_crtc(crtc, dev) {
> > >>> +   if (!ww_mutex_trylock(&crtc->mutex.mutex))
> > >>> +   continue;
> > >>> +
> > >>> +   if (!crtc->enabled || !crtc->primary)
> > >>> +   goto crtc_unlock;
> > >>> +
> > >>> +   if (!crtc->state || !crtc->state->active)
> > >>> +   goto crtc_unlock;
> > >>> +
> > >>> +   plane = crtc->primary;
> > >>> +   if (!ww_mutex_trylock(&plane->mutex.mutex))
> > >>> +   goto crtc_unlock;
> > >>> +
> > >>> +   /*
> > >>> +* TODO: Should we check plane_state->visible?
> > >>> +* It is not set on vc4
> > >>
> > >> I think we should. We should also check whether that primary is connected
> > >> to the crtc (some hw you can reassign planes freely between crtc, and the
> > >> crtc->primary pointer is only used for compat with legacy ioctl).
> > >>
> > >>> +   if (!plane->state || !plane->state->visible)
> > >>> +*/
> > >>> +   if (!plane->state)
> > >>> +   goto plane_unlock;
> > >>> +
> > >>> +   fb = plane->state->fb;
> > >>> +   if (!fb || !fb->funcs->panic_vmap)
> > >>
> > >> Docs says this is optional, doesn't seem to be all that optional. I'd
> > >> check for this or a driver-specific ->panic_draw_xy instead.
> > >>> +   goto plane_unlock;
> > >>> +
> > >>> +   /*
> > >>> +* fbcon puts out panic messages so stay away to avoid 
> > >>> jumbled
> > >>> +* output. If vc->vc_mode != KD_TEXT fbcon won't put out
> > >>> +* messages (see vt_console_print).
> > >>> +*/
> > >>> +   if (dev->fb_helper && dev->fb_helper->fb == fb)
> > > 
> > > This is a bit a layering violation. Could we instead tell fbcon that it
> > > shouldn't do panic handling for drm drivers? I think that would resolve
> > > this overlap here in a much cleaner way. drm fbdev helpers already have
> > > lots of oops_in_progress checks all over to make sure fbcon doesn't do
> > > anything bad. That only leaves the actual rendering, which I think we can
> > > stop too with a simple flag.
> > > 
> > > Ofc only for atomic drivers which have this panic handling mode here
> > > implemented.
> > 
> > There used to be a fbdev flag FBINFO_CAN_FORCE_OUTPUT that controlled
> > vc->vc_panic_force_write, but it's gone now I see.
> 
> I killed that :-)
> 
> Looking at those patches again, it's not what we wanted. It was used to
> force panic display even when not in KD_TEXT mode.
> 
> What we want instead here is a flag to tell fbcon/vt to _never_ write
> dmesg to our console, not even when the console is in KD_TEXT mode.
> Because we have a separate panic handler to display it. Heck maybe that QR
> code thing could be resurrected eventually again.
> 
> Totally untested snippet below is what I'm thinking of:
> 
> 
> diff --git a/drivers/video/fbdev/core/fbcon.c 
> b/drivers/video/fbdev/core/fbcon.c
> index 7f4c22a65f63..b08c63286ed0 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -282,6 +282,9 @@ static inline int fbcon_is_inactive(struct vc_data *vc, 
> struct fb_info *info)
>  {
>   struct fbcon_ops *ops = info->fbcon_par;
>  
> + if (oops_in_progress && info->flags & NO_OOPS_OUTPUT)
> + return false;
> +
>   return (info->state != FBINFO_STATE_RUNNING ||
>   vc->vc_mode != KD_TEXT || ops->graphics);
>  }
> 
> 
> Plus then unconditionally rendering the oops output on the drm side, even
> i

[Bug 109974] libgl will not load radeonsi on X running using DRM lease

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109974

Bug ID: 109974
   Summary: libgl will not load radeonsi on X running using DRM
lease
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: p...@polepetko.eu
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 143631
  --> https://bugs.freedesktop.org/attachment.cgi?id=143631&action=edit
Xorg log

Running any OpenGL application on X running using DRM lease will result in
fallback to swrast.
But the modesseting driver is able to use radeonsi for glamor.

LIBGL_DEBUG=verbose glxinfo | grep OpenGL
libGL: screen 0 does not appear to be DRI3 capable
libGL error: failed to authenticate magic 10
libGL error: failed to load driver: radeonsi
libGL: MESA-LOADER: dlopen(/usr/lib64/dri/swrast_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 7.0, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.1.0-devel
(git-9ab1b1d022)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 19.1.0-devel (git-9ab1b1d022)
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 19.1.0-devel
(git-9ab1b1d022)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Xorg 1.20.4
libdrm 2.4.97
Mesa 19.1.0-devel (git-9ab1b1d022)
kernel 5.0.0-gentoo

-- 
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 109974] libgl will not load radeonsi on X running using DRM lease

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109974

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #143631|text/x-log  |text/plain
  mime type||

-- 
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 109974] libgl will not load radeonsi on X running using DRM lease

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109974

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #1 from Michel Dänzer  ---
AFAICT this is due to the Xorg modesetting driver / glamor still relying on
drmGet/AuthMagic even for DRI3 clients. Please file an issue at
https://gitlab.freedesktop.org/xorg/xserver/issues/new?issue .

Meanwhile, you can try xf86-video-amdgpu, which uses DRM render nodes for DRI3
clients if available.

-- 
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: DRM-based Oops viewer

[Jani Nikula]

On Mon, 11 Mar 2019, "Ahmed S. Darwish"  wrote:
> Hello Jani,
>
> On Mon, Mar 11, 2019 at 11:04:19AM +0200, Jani Nikula wrote:
>> On Sun, 10 Mar 2019, "Ahmed S. Darwish"  wrote:
>> Please first better define what you want to achieve.
>>
>
> Oh I thought this was clear..
>
> What I want to achieve is:
>
>   - for normal day-to-day x86 laptops users
>   - properly inform the user when a kernel panic happens during
> a running graphical session (e.g. wayland/gnome/kde/...).

Thanks for the detailed reply. It always helps to start with the problem
you want to solve or end goal you want to reach.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109975] personal banking button is not working

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109975

Bug ID: 109975
   Summary: personal banking button is not working
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu-pro
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ramanavaizurs3...@gmail.com

Created attachment 143632
  --> https://bugs.freedesktop.org/attachment.cgi?id=143632&action=edit
personal banking button is not working

enter valid URL click on go
In visitor flow personal banking button is not displayed

-- 
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 109975] personal banking button is not working

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109975

ramana  changed:

   What|Removed |Added

URL||http://192.168.1.97/ebank2/
   ||home.aspx

-- 
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 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104602

oliver.trie...@haspa.de changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #19 from oliver.trie...@haspa.de ---
I also confirm success on Ryzen 2200g system.

Steam launch property `R600_DEBUG=nir %command%`
fixed texture flickering/artifacts in CIV6 (that appeared on strategic map).


olly@ryzen-pc1:~$ uname -a
Linux ryzen-pc1 5.0.0-05-generic #201903032031 SMP Mon Mar 4 01:33:18 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
olly@ryzen-pc1:~$ glxinfo | grep "OpenGL version"
OpenGL version string: 4.5 (Compatibility Profile) Mesa 18.3.3
olly@ryzen-pc1:~$ lspci -nnk | grep -i VGA -A2 
38:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series]
[1002:15dd] (rev c8)
    Subsystem: Micro-Star International Co., Ltd. [MSI] Vega [Radeon Vega 8
Mobile] [1462:7a39]
    Kernel driver in use: amdgpu
olly@ryzen-pc1:~$ lsb_release -a
No LSB modules are available.
Description:    Ubuntu 18.04.2 LTS

-- 
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 v2 1/3] drm: Add support for panic message output

[Michel Dänzer]

On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> This adds support for outputting kernel messages on panic().
> A kernel message dumper is used to dump the log. The dumper iterates
> over each DRM device and it's crtc's to find suitable framebuffers.
> 
> All the other dumpers are run before this one except mtdoops.
> Only atomic drivers are supported.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  [...]
> 
> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
> index f0b34c977ec5..f3274798ecfe 100644
> --- a/include/drm/drm_framebuffer.h
> +++ b/include/drm/drm_framebuffer.h
> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
>struct drm_file *file_priv, unsigned flags,
>unsigned color, struct drm_clip_rect *clips,
>unsigned num_clips);
> +
> + /**
> +  * @panic_vmap:
> +  *
> +  * Optional callback for panic handling.
> +  *
> +  * For vmapping the selected framebuffer in a panic context. Must
> +  * be super careful about locking (only trylocking allowed).
> +  *
> +  * RETURNS:
> +  *
> +  * NULL if it didn't work out, otherwise an opaque cookie which is
> +  * passed to @panic_draw_xy. It can be anything: vmap area, structure
> +  * with more details, just a few flags, ...
> +  */
> + void *(*panic_vmap)(struct drm_framebuffer *fb);

FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
drivers:

Framebuffers are normally tiled, writing to them with the CPU results in
garbled output.

With a discrete GPU having a large amount of VRAM, the framebuffer may
not be directly CPU accessible at all.


There would need to be a mechanism for switching scanout to a linear,
CPU accessible framebuffer.


-- 
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 2019 X.Org Foundation Election Candidates

[Luc Verhaegen]

On Tue, Mar 12, 2019 at 12:24:00AM +, Wentland, Harry wrote:
> To all X.Org Foundation Members:
> 
> The election for the X.Org Foundation Board of Directors will begin on 
> 14 March 2019. We have 6 candidates who are running for 4 seats. They 
> are (in alphabetical order):

> Attached below are the Personal Statements each candidate submitted 
> for your consideration along with their Statements of Contribution 
> that they submitted with the membership application. Please review 
> each of the candidates' statements to help you decide whom to vote for 
> during the upcoming election.
> 
> If you have questions of the candidates, you should feel free to ask them 
> here on the mailing list.
> 
> The election committee will provide detailed instructions on how the voting 
> system will work when the voting period begins.
> 
> Harry, on behalf of the X.Org elections committee

Are these candidates the only thing we will be voting on?

Luc Verhaegen.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] drm: Add support for panic message output

[Daniel Vetter]

On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
> 
> 
> Den 11.03.2019 20.23, skrev Daniel Vetter:
> > On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> >> This adds support for outputting kernel messages on panic().
> >> A kernel message dumper is used to dump the log. The dumper iterates
> >> over each DRM device and it's crtc's to find suitable framebuffers.
> >>
> >> All the other dumpers are run before this one except mtdoops.
> >> Only atomic drivers are supported.
> >>
> >> Signed-off-by: Noralf Trønnes 
> > 
> > Bunch of comments/ideas for you or Darwish below, whoever picks this up.
> 
> Actually it would ne nice if Darwish could pick it up since he will do
> it on i915 which will be useful to a much broader audience.
> If not I'll respin when I'm done with the drm_fb_helper refactoring.
> 
> 
> 
> >> diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c
> >> new file mode 100644
> >> index ..4bca7f0bc369
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/drm_panic.c
> >> @@ -0,0 +1,363 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +// Copyright 2018 Noralf Trønnes
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include "drm_internal.h"
> >> +
> >> +/*
> >> + * The log lines in an ARM stack dump are 92 characters long
> >> + * and 120 is a nice multiple for HD and 4K.
> >> + */
> >> +#define DRM_PANIC_COLUMN_WIDTH120
> > 
> > I think we should compute this dynamically from the actual fb width and
> > font witdth.
> 
> The font is picked based on whether it can fit 50 lines of text.
> 
> The next rule is to decide when to add another column. I decided to use
> a number that gets most log lines in one line on the screen. If most
> lines get broken into two lines, there's not much use in an extra column.
> 
> Do you have another idea on how to do this?
> 
> (There's even a 16x32 font now that wasn't available when I did this.)

Oh I had no idea that this is for multi-column oops printing. That's
indeed neat for 4k screens.
> 
> > 
> >> +
> >> +struct drm_panic_ctx {
> >> +  struct drm_framebuffer *fb;
> >> +  unsigned int width;
> >> +  unsigned int height;
> >> +  void *vmap;
> >> +
> >> +  const struct font_desc *font;
> >> +  unsigned int col_width;
> >> +  unsigned int bottom_y;
> >> +  size_t max_line_length;
> >> +
> >> +  unsigned int x;
> >> +  unsigned int y;
> >> +};
> >> +
> >> +static const struct font_desc *drm_panic_font8x8, *drm_panic_font8x16;
> >> +
> >> +static void drm_panic_draw_xy(struct drm_framebuffer *fb, void *vmap,
> >> +int x, int y, bool fg)
> >> +{
> >> +  if (fb->funcs->panic_draw_xy)
> >> +  fb->funcs->panic_draw_xy(fb, vmap, x, y, fg);
> >> +  else
> >> +  drm_framebuffer_panic_draw_xy(fb, vmap, x, y, fg);
> >> +}
> >> +
> >> +static void drm_panic_render_char(struct drm_panic_ctx *ctx,
> >> +unsigned int offset, char c)
> >> +{
> >> +  unsigned int h, w, x, y;
> >> +  u8 fontline;
> >> +
> >> +  for (h = 0; h < ctx->font->height; h++) {
> >> +  fontline = *(u8 *)(ctx->font->data + c * ctx->font->height + h);
> >> +
> >> +  for (w = 0; w < ctx->font->width; w++) {
> >> +  x = ctx->x + (offset * ctx->font->width) + w;
> >> +  y = ctx->y + h;
> >> +  drm_panic_draw_xy(ctx->fb, ctx->vmap, x, y,
> >> +fontline & BIT(7 - w));
> >> +  }
> >> +  }
> >> +}
> >> +
> >> +static void drm_panic_render_line(struct drm_panic_ctx *ctx,
> >> +const char *line, size_t len)
> >> +{
> >> +  unsigned int i;
> >> +
> >> +  for (i = 0; i < len; i++)
> >> +  drm_panic_render_char(ctx, i, line[i]);
> >> +
> >> +  /* Clear out the rest of the line */
> >> +  for (i = len; i < ctx->max_line_length; i++)
> >> +  drm_panic_render_char(ctx, i, ' ');
> >> +}
> >> +
> >> +static bool drm_panic_newline(struct drm_panic_ctx *ctx)
> >> +{
> >> +  if (ctx->x == 0 && ctx->y == 0)
> >> +  return false;
> >> +  if (ctx->y == 0) {
> >> +  ctx->x -= ctx->col_width;
> >> +  ctx->y = ctx->bottom_y;
> >> +  } else {
> >> +  ctx->y -= ctx->font->height;
> >> +  }
> >> +
> >> +  return true;
> >> +}
> >> +
> >> +/* Render from bottom right most column */
> >> +static bool drm_panic_render_lines(struct drm_panic_ctx *ctx,
> >> + const char *str, size_t len)
> >> +{
> >> +  size_t l, line_length;
> >> +  const char *pos;
> >> +  int i;
> >> +
> >> +  while (len) {
> >> +  pos = str + len - 1;
> >> +
> >> +  if (*pos == '\n') {
> >> +  len--;
> >> +  if (!drm_panic_newline(ctx))
> >> +   

Re: [PATCH] drm/atomic-helper: Validate pointer before dereference

[Daniel Vetter]

On Mon, Mar 11, 2019 at 06:01:20PM -0300, Rodrigo Siqueira wrote:
> The function disable_outputs() and
> drm_atomic_helper_commit_modeset_enables() tries to retrieve
> helper_private from the target CRTC, for dereferencing some operations.
> However, the current implementation does not check whether
> helper_private is null and, if not, if it has a valid pointer to a dpms
> and commit functions. This commit adds pointer validations before
> trying to dereference the dpms and commit function.
> 
> Signed-off-by: Rodrigo Siqueira 

Please also adjust the kerneldoc for these functions. And I think the
patch subject can be improved, e.g. "Make ->atomic_enable/disable crtc
callbacks optional". Describe what you're trying to achieve in the
summary, not how you achieve it.
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 30 -
>  1 file changed, 17 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 540a77a2ade9..fbeef7c461fc 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1028,14 +1028,16 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>  
>  
>   /* Right function depends upon target state. */
> - if (new_crtc_state->enable && funcs->prepare)
> - funcs->prepare(crtc);
> - else if (funcs->atomic_disable)
> - funcs->atomic_disable(crtc, old_crtc_state);
> - else if (funcs->disable)
> - funcs->disable(crtc);
> - else
> - funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> + if (funcs) {

I don't think making funcs optional is a good idea. If you have a crtc
with no functions implemented, it's not terribly useful.

Also making functions optional just here is not going to help if we still
require it everywhere else.
-Daniel

> + if (new_crtc_state->enable && funcs->prepare)
> + funcs->prepare(crtc);
> + else if (funcs->atomic_disable)
> + funcs->atomic_disable(crtc, old_crtc_state);
> + else if (funcs->disable)
> + funcs->disable(crtc);
> + else if (funcs->dpms)
> + funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> + }
>  
>   if (!(dev->irq_enabled && dev->num_crtcs))
>   continue;
> @@ -1277,11 +1279,13 @@ void drm_atomic_helper_commit_modeset_enables(struct 
> drm_device *dev,
>   if (new_crtc_state->enable) {
>   DRM_DEBUG_ATOMIC("enabling [CRTC:%d:%s]\n",
>crtc->base.id, crtc->name);
> -
> - if (funcs->atomic_enable)
> - funcs->atomic_enable(crtc, old_crtc_state);
> - else
> - funcs->commit(crtc);
> + if (funcs) {
> + if (funcs->atomic_enable)
> + funcs->atomic_enable(crtc,
> +  old_crtc_state);
> + else if (funcs->atomic_enable)
> + funcs->commit(crtc);
> + }
>   }
>   }
>  
> -- 
> 2.21.0

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/5] drm/rockchip: fix fb references in async update

[Daniel Vetter]

On Tue, Mar 12, 2019 at 07:34:38AM +0100, Boris Brezillon wrote:
> On Mon, 11 Mar 2019 23:21:59 -0300
> Helen Koike  wrote:
> 
> > In the case of async update, modifications are done in place, i.e. in the
> > current plane state, so the new_state is prepared and the new_state is
> > cleanup up (instead of the old_state, diferrently on what happen in a
> 
>   ^ cleaned up^ differently (but maybe
> "unlike what happens" is more appropriate here).
> 
> > normal sync update).
> > To cleanup the old_fb properly, it needs to be placed in the new_state
> > in the end of async_update, so cleanup call will unreference the old_fb
> > correctly.
> > 
> > Also, the previous code had a:
> > 
> > plane_state = plane->funcs->atomic_duplicate_state(plane);
> > ...
> > swap(plane_state, plane->state);
> > 
> > if (plane->state->fb && plane->state->fb != new_state->fb) {
> > ...
> > }
> > 
> > Which was wrong, as the fb were just assigned to be equal, so this if
> > statement nevers evaluates to true.
> > 
> > Another details is that the function drm_crtc_vblank_get() can only be
> > called when vop->is_enabled is true, otherwise it has no effect and
> > trows a WARN_ON().
> > 
> > Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
> > fb and pus the old fb) is not required, as it is taken care by
> > drm_mode_cursor_universal() when calling
> > drm_atomic_helper_update_plane().
> > 
> > Signed-off-by: Helen Koike 
> > 
> > ---
> > Hello,
> > 
> > I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
> > kms_cursor_legacy and I didn't see any regressions.
> > 
> > Changes in v2: None
> > 
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 -
> >  1 file changed, 24 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index c7d4c6073ea5..a1ee8c156a7b 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -912,30 +912,31 @@ static void vop_plane_atomic_async_update(struct 
> > drm_plane *plane,
> >   struct drm_plane_state *new_state)
> >  {
> > struct vop *vop = to_vop(plane->state->crtc);
> > -   struct drm_plane_state *plane_state;
> > +   struct drm_framebuffer *old_fb = plane->state->fb;
> >  
> > -   plane_state = plane->funcs->atomic_duplicate_state(plane);
> > -   plane_state->crtc_x = new_state->crtc_x;
> > -   plane_state->crtc_y = new_state->crtc_y;
> > -   plane_state->crtc_h = new_state->crtc_h;
> > -   plane_state->crtc_w = new_state->crtc_w;
> > -   plane_state->src_x = new_state->src_x;
> > -   plane_state->src_y = new_state->src_y;
> > -   plane_state->src_h = new_state->src_h;
> > -   plane_state->src_w = new_state->src_w;
> > -
> > -   if (plane_state->fb != new_state->fb)
> > -   drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
> > -
> > -   swap(plane_state, plane->state);
> > -
> > -   if (plane->state->fb && plane->state->fb != new_state->fb) {
> > +   /*
> > +* A scanout can still be occurring, so we can't drop the reference to
> > +* the old framebuffer. To solve this we get a reference to old_fb and
> > +* set a worker to release it later.
> 
> Hm, doesn't look like an async update to me if we have to wait for the
> next VBLANK to happen to get the new content on the screen. Maybe we
> should reject async updates when old_fb != new_fb in the rk
> ->async_check() hook. 

Scanning out garbage because the old buffer is unpinned too quickly is one
of the long-term "features" of async updates. At least for features.

It's another one of these things we need to fix. Which might become easier
if we switch to usual state switching, since then we can punt the
cleanup_plane phase to a worker.

Note that depending upon the gpu this might not just result in garbage but
hangs, usually when there's an iommu and the chip dies if it accesses an
unmapped page.

Probably something to fix later on in async framework.
-Daniel
> 
> > +*/
> > +   if (vop->is_enabled &&
> > +   plane->state->fb && plane->state->fb != new_state->fb) {
> > drm_framebuffer_get(plane->state->fb);
> > WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
> > drm_flip_work_queue(&vop->fb_unref_work, plane->state->fb);
> > set_bit(VOP_PENDING_FB_UNREF, &vop->pending);
> > }
> 
> In any case, I think this should be called after
> vop_plane_atomic_update() to prevent the situation where the VBLANK
> event happens between this point and the following
> vop_plane_atomic_update() call.
> 
> >  
> > +   plane->state->crtc_x = new_state->crtc_x;
> > +   plane->state->crtc_y = new_state->crtc_y;
> > +   plane->state->crtc_h = new_state->crtc_h;
> > +   plane->state->crtc_w = new_state->crtc_w;
> > +   plane->state->src_x = new_state->src_x;
> > +   plan

[Bug 109977] Segmentation fault in drmParsePlatformDeviceInfo

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109977

Bug ID: 109977
   Summary: Segmentation fault in drmParsePlatformDeviceInfo
   Product: DRI
   Version: XOrg git
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: libdrm
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ich...@imkreisrum.de

Created attachment 143633
  --> https://bugs.freedesktop.org/attachment.cgi?id=143633&action=edit
[PATCH libdrm] xf86drm: Fix segmentation fault while parsing device  info

Since commit ee798b98479709acdd8d1492689dc93c1a62f239 (xf85drm: de-duplicate
drmParse{Platform.Host1x}{Bus,Device}Info)

I encounter a segfault at line 3632:

 *compatible[i] = tmp_name;

Libdrm segfaults as soon as i>0. 

This was encountered on armhf platform (Allwinner A10) with kernel 5.0
including drm-misc-next and the lima driver
(https://gitlab.freedesktop.org/lima/linux/commits/lima-drm-misc-next-20190309)
and the lima mesa branch (https://gitlab.freedesktop.org/lima/mesa) while
running glmark2-es2-drm and kmscube.

You can see the original issue including backtrace and strace reported here:
https://gitlab.freedesktop.org/lima/mesa/issues/80#note_129271

The attached patch fixes it.

-- 
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] drm/atomic-helper: Validate pointer before dereference

[Rodrigo Siqueira]

Hi,

First of all, thanks for the feedback.

I will fix all the problems pointed out in the review.

I just have two inline questions.

On 03/12, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 06:01:20PM -0300, Rodrigo Siqueira wrote:
> > The function disable_outputs() and
> > drm_atomic_helper_commit_modeset_enables() tries to retrieve
> > helper_private from the target CRTC, for dereferencing some operations.
> > However, the current implementation does not check whether
> > helper_private is null and, if not, if it has a valid pointer to a dpms
> > and commit functions. This commit adds pointer validations before
> > trying to dereference the dpms and commit function.
> > 
> > Signed-off-by: Rodrigo Siqueira 
> 
> Please also adjust the kerneldoc for these functions. And I think the
> patch subject can be improved, e.g. "Make ->atomic_enable/disable crtc
> callbacks optional". Describe what you're trying to achieve in the
> summary, not how you achieve it.

Do I need to add information which says that both functions are
optional? I'm asking because the description related to the affected
functions and struct looks good for me [1,2,3].

1. Documentation for drm_crtc_helper_funcs:
https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html?highlight=drm_crtc_helper_funcs#c.drm_crtc_helper_funcs

2. Documentation for drm_atomic_helper_commit_modeset_enables():
https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html?highlight=drm_atomic_helper_commit_modeset_enables#c.drm_atomic_helper_commit_modeset_enables

3. Documentation for drm_atomic_helper_commit_modeset_disables():
https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html?highlight=drm_atomic_helper_commit_modeset_disables#c.drm_atomic_helper_commit_modeset_disables

> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 30 -
> >  1 file changed, 17 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 540a77a2ade9..fbeef7c461fc 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1028,14 +1028,16 @@ disable_outputs(struct drm_device *dev, struct 
> > drm_atomic_state *old_state)
> >  
> >  
> > /* Right function depends upon target state. */
> > -   if (new_crtc_state->enable && funcs->prepare)
> > -   funcs->prepare(crtc);
> > -   else if (funcs->atomic_disable)
> > -   funcs->atomic_disable(crtc, old_crtc_state);
> > -   else if (funcs->disable)
> > -   funcs->disable(crtc);
> > -   else
> > -   funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> > +   if (funcs) {
> 
> I don't think making funcs optional is a good idea. If you have a crtc
> with no functions implemented, it's not terribly useful.
> 
> Also making functions optional just here is not going to help if we still
> require it everywhere else.

Should I remove the other occurrence of "if (funcs)" inside
disable_outputs() and drm_atomic_helper_commit_modeset_enables()? Both
functions, already had this before.

Best Regards

> -Daniel
> 
> > +   if (new_crtc_state->enable && funcs->prepare)
> > +   funcs->prepare(crtc);
> > +   else if (funcs->atomic_disable)
> > +   funcs->atomic_disable(crtc, old_crtc_state);
> > +   else if (funcs->disable)
> > +   funcs->disable(crtc);
> > +   else if (funcs->dpms)
> > +   funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> > +   }
> >  
> > if (!(dev->irq_enabled && dev->num_crtcs))
> > continue;
> > @@ -1277,11 +1279,13 @@ void 
> > drm_atomic_helper_commit_modeset_enables(struct drm_device *dev,
> > if (new_crtc_state->enable) {
> > DRM_DEBUG_ATOMIC("enabling [CRTC:%d:%s]\n",
> >  crtc->base.id, crtc->name);
> > -
> > -   if (funcs->atomic_enable)
> > -   funcs->atomic_enable(crtc, old_crtc_state);
> > -   else
> > -   funcs->commit(crtc);
> > +   if (funcs) {
> > +   if (funcs->atomic_enable)
> > +   funcs->atomic_enable(crtc,
> > +old_crtc_state);
> > +   else if (funcs->atomic_enable)
> > +   funcs->commit(crtc);
> > +   }
> > }
> > }
> >  
> > -- 
> > 2.21.0
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
___
dri-devel mailing li

Re: [PATCH v2 5/5] drm: don't block fb changes for async plane updates

[Kazlauskas, Nicholas]

On 3/12/19 2:44 AM, Boris Brezillon wrote:
> On Mon, 11 Mar 2019 23:22:03 -0300
> Helen Koike  wrote:
> 
>> In the case of a normal sync update, the preparation of framebuffers (be
>> it calling drm_atomic_helper_prepare_planes() or doing setups with
>> drm_framebuffer_get()) are performed in the new_state and the respective
>> cleanups are performed in the old_state.
>>
>> In the case of async updates, the preparation is also done in the
>> new_state but the cleanups are done in the new_state (because updates
>> are performed in place, i.e. in the current state).
>>
>> The current code blocks async udpates when the fb is changed, turning
>> async updates into sync updates, slowing down cursor updates and
>> introducing regressions in igt tests with errors of type:
>>
>> "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
>> expect to complete approximately 15360 updates, with the threshold set
>> at 7680"
>>
>> Fb changes in async updates were prevented to avoid the following scenario:
>>
>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 
>> (wrong)
>> Where we have a single call to prepare fb2 but double cleanup call to fb2.
>>
>> To solve the above problems, instead of blocking async fb changes, we
>> place the old framebuffer in the new_state object, so when the code
>> performs cleanups in the new_state it will cleanup the old_fb and we
>> will have the following scenario instead:
>>
>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
>>
>> Where calls to prepare/cleanup are balanced.
>>
>> Cc:  # v4.14+
>> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
>> Suggested-by: Boris Brezillon 
>> Signed-off-by: Helen Koike 
> 
> Reviewed-by: Boris Brezillon 

Reviewed-by: Nicholas Kazlauskas 

I was thinking that the comment could go in async_commit or async_check, 
but I guess it works there too. Maybe it needs a FIXME or a TODO for a 
full state swap, but these are just nitpicks.

Nicholas Kazlauskas

> 
>>
>> ---
>> Hello,
>>
>> As mentioned in the cover letter, I tested in almost all platforms with
>> igt plane_cursor_legacy and kms_cursor_legacy and I didn't see any
>> regressions. But I couldn't test on MSM and AMD because I don't have
>> the hardware I would appreciate if anyone could help me testing those.
>>
>> Thanks!
>> Helen
>>
>> Changes in v2:
>> - Change the order of the patch in the series, add this as the last one.
>> - Add documentation
>> - s/ballanced/balanced
>>
>>   drivers/gpu/drm/drm_atomic_helper.c  | 20 ++--
>>   include/drm/drm_modeset_helper_vtables.h |  5 +
>>   2 files changed, 15 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 540a77a2ade9..e7eb96f1efc2 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct drm_device 
>> *dev,
>>  old_plane_state->crtc != new_plane_state->crtc)
>>  return -EINVAL;
>>   
>> -/*
>> - * FIXME: Since prepare_fb and cleanup_fb are always called on
>> - * the new_plane_state for async updates we need to block framebuffer
>> - * changes. This prevents use of a fb that's been cleaned up and
>> - * double cleanups from occuring.
>> - */
>> -if (old_plane_state->fb != new_plane_state->fb)
>> -return -EINVAL;
>> -
>>  funcs = plane->helper_private;
>>  if (!funcs->atomic_async_update)
>>  return -EINVAL;
>> @@ -1657,6 +1648,9 @@ void drm_atomic_helper_async_commit(struct drm_device 
>> *dev,
>>  int i;
>>   
>>  for_each_new_plane_in_state(state, plane, plane_state, i) {
>> +struct drm_framebuffer *new_fb = plane_state->fb;
>> +struct drm_framebuffer *old_fb = plane->state->fb;
>> +
>>  funcs = plane->helper_private;
>>  funcs->atomic_async_update(plane, plane_state);
>>   
>> @@ -1665,11 +1659,17 @@ void drm_atomic_helper_async_commit(struct 
>> drm_device *dev,
>>   * plane->state in-place, make sure at least common
>>   * properties have been properly updated.
>>   */
>> -WARN_ON_ONCE(plane->state->fb != plane_state->fb);
>> +WARN_ON_ONCE(plane->state->fb != new_fb);
>>  WARN_ON_ONCE(plane->state->crtc_x != plane_state->crtc_x);
>>  WARN_ON_ONCE(plane->state->crtc_y != plane_state->crtc_y);
>>  WARN_ON_ONCE(plane->state->src_x != plane_state->src_x);
>>  WARN_ON_ONCE(plane->state->src_y != plane_state->src_y);
>> +
>> +/*
>>

[Bug 109977] Segmentation fault in drmParsePlatformDeviceInfo

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109977

Eric Engestrom  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||emil.l.veli...@gmail.com

--- Comment #1 from Eric Engestrom  ---
Thanks!
Your fix is correct, although partial: the same bug appears again in the free()
a couple lines below.
I've added it as part of your patch and pushed it:

commit 4735ca71af9f741e2438104d543dc3c5a8107f35
Author: Andreas Baierl 
Date:   Mon Mar 11 16:04:08 2019 +0100

xf86drm: Fix segmentation fault while parsing device info

This fixes a bug, which was introduced with commit ee798b98
"xf85drm: de-duplicate drmParse{Platform.Host1x}{Bus,Device}Info".
where accessing *compatible[i] with i>0 results in a segfault.

Signed-off-by: Andreas Baierl 
Fixes: ee798b98479709acdd8d "xf85drm: de-duplicate
drmParse{Platform.Host1x}{Bus,Device}Info"
Reviewed-by: Eric Engestrom 
[Eric: add the same fix to the free() below]
Signed-off-by: Eric Engestrom 

-- 
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 201957] amdgpu: ring gfx timeout

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=201957

Cameron (ker...@cameron.bz) changed:

   What|Removed |Added

 CC||ker...@cameron.bz

--- Comment #5 from Cameron (ker...@cameron.bz) ---
I'm having a very similar issue, running Linux Mint 19.1. The issue has
persisted from at least 4.15, I'm currently running 5.0.1 and the issue
remains. 

Here is the latest syslog of the error:

[37258.615599] gmc_v9_0_process_interrupt: 10 callbacks suppressed
[37258.615608] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317)
[37258.615615] amdgpu :06:00.0:   in page starting at address
0x800107805000 from 27
[37258.615619] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00301031
[37258.615629] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317)
[37258.615633] amdgpu :06:00.0:   in page starting at address
0x800107807000 from 27
[37258.615636] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x
[37258.615645] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317)
[37258.615648] amdgpu :06:00.0:   in page starting at address
0x800107801000 from 27
[37258.615651] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x
[37258.615660] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317)
[37258.615663] amdgpu :06:00.0:   in page starting at address
0x800107803000 from 27
[37258.615666] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x
[37258.615675] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317)
[37258.615678] amdgpu :06:00.0:   in page starting at address
0x800107809000 from 27
[37258.615681] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x
[37258.615689] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317)
[37258.615692] amdgpu :06:00.0:   in page starting at address
0x80010780b000 from 27
[37258.615695] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x
[37258.615704] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317)
[37258.615707] amdgpu :06:00.0:   in page starting at address
0x800107805000 from 27
[37258.615710] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x
[37258.615740] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317)
[37258.615743] amdgpu :06:00.0:   in page starting at address
0x800107807000 from 27
[37258.615746] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x
[37258.615756] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317)
[37258.615759] amdgpu :06:00.0:   in page starting at address
0x800107801000 from 27
[37258.615762] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x
[37258.615771] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317)
[37258.615774] amdgpu :06:00.0:   in page starting at address
0x800107803000 from 27
[37258.615777] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x
[37268.712339] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
signaled seq=602475, emitted seq=602478
[37268.712387] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process Xorg pid 1287 thread Xorg:cs0 pid 1317
[37268.712389] [drm] GPU recovery disabled.
[37278.952537] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
signaled seq=602475, emitted seq=602478
[37278.952624] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process Xorg pid 1287 thread Xorg:cs0 pid 1317
[37278.952628] [drm] GPU recovery disabled.
[37289.192390] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
signaled seq=602475, emitted seq=602478
[37289.192478] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process Xorg pid 1287 thread Xorg:cs0 pid 1317
[37289.192481] [drm] GPU recovery disabled.
[37299.432447] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
signaled seq=602475, emitted seq=602478
[37299.432534] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process Xorg pid 1287 thread Xorg:cs0 pid 1317
[37299.432538] [drm] GPU recovery disabled.
[37309.676431] [drm:amdgpu_job_timedout [amdgpu]] 

Re: [PATCH v2 1/3] drm: Add support for panic message output

[Noralf Trønnes]

Den 12.03.2019 11.58, skrev Daniel Vetter:
> On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 11.03.2019 20.23, skrev Daniel Vetter:
>>> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
 This adds support for outputting kernel messages on panic().
 A kernel message dumper is used to dump the log. The dumper iterates
 over each DRM device and it's crtc's to find suitable framebuffers.

 All the other dumpers are run before this one except mtdoops.
 Only atomic drivers are supported.

 Signed-off-by: Noralf Trønnes 
>>>



 +static void drm_panic_kmsg_render_screen(struct drm_plane *plane,
 +   struct kmsg_dumper *dumper)
 +{
 +  struct drm_framebuffer *fb = plane->state->fb;
 +  bool first_iteration = true;
 +  struct drm_panic_ctx ctx;
 +  static char text[1024];
 +  size_t len;
 +
 +  ctx.vmap = fb->funcs->panic_vmap(fb);
 +
 +  /* Print some info when testing */
 +  if (dumper->max_reason == KMSG_DUMP_OOPS) {
 +  struct drm_format_name_buf format_name;
 +
 +  pr_info("%s: [FB:%d] %ux%u format=%s vmap=%p\n",
 +  __func__, fb->base.id, fb->width, fb->height,
 +  drm_get_format_name(fb->format->format, &format_name),
 +  ctx.vmap);
 +  }
 +
 +  if (!ctx.vmap)
 +  return;
>>>
>>> For some framebuffers it might be useful to not require vmap, but instead
>>> have some page-by-page kind of access helper. Since preemptively setting
>>> up a vmap for all the non-continous buffers is a bit much, and we really
>>> can't set up the vmap in the panic handler.
>>>
>>> Maybe we should call this panic_prepare/panic_finish and
>>> s/vmap/cookie/, to make it entirely opaque?
>>>
>>> But a bit overengineering perhaps :-)
>>>
>>
>> I guess i915 wants something else than vmap, but I have no idea how a
>> page-by-page solution is to be implemented.
> 
> i915 should be mostly fine, since we have a GTT for remapping and can make
> it look continuous. It might not be in the part of the GTT accessible by
> the cpu though.
> 
> Wrt implementation: My idea would be to extract the pixel writing function
> and export it to drivers. The driver would then implement a
> ->panic_draw_xy function which looks up the right page, computes it
> address, computes the x/y offset within (taking into account tiling and
> stuff like that), and then uses the helper function to draw the right
> pixel value for the format at the given address.
> 
> That's why I suggested that drivers need to either implement
> ->panic_prepare or ->panic_draw_xy. Since for this approach you might not
> need a ->panic_prepare/cleanup implementation, since it's all done in
> ->panic_draw_xy on a pixel-by-pixel basis.
> 
>> When we get bootsplash, we will at least have a kernel address during
>> that phase for all drivers supporting it.
> 
> Hm, not following what you mean here. Why is bootsplash special?
> 

Special in the sense that it's framebuffer will be linear and already
have a virtual address for its backing buffer since that's a
prerequisite for it to render the splash image.

Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109978] Unprivileged user mode program can cause GPU reset

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109978

Bug ID: 109978
   Summary: Unprivileged user mode program can cause GPU reset
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/amdkfd
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: sudols...@gmail.com

https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/issues/72

Sample program which causes this (needs ROCm):

> #include 
> int main()
> {
>   parallel_for_each(hc::extent<1>(1), [=]() [[hc]]
>   {
>   asm("s_trap 2");
>   });
>   return 0;
> }

> hcc -hc main.cpp
> ./a.out

Process never ends and CTRL-C causes GPU reset which breaks all other processes
actually using rocm on that GPU. Seems trap handler expects queue handle in
s[0:1] which is set when using __builtin_trap() so without it trap handler
causes another exceptions.

System logs:

[  247.428727] qcm fence wait loop timeout expired
[  247.428730] The cp might be in an unrecoverable state due to an unsuccessful
queues preemption
[  247.428736] amdgpu :0b:00.0: GPU reset begin!
[  247.619440] amdgpu :0b:00.0: GPU reset
[  248.152762] [drm] psp mode1 reset succeed 
[  248.279461] amdgpu :0b:00.0: GPU reset succeeded, trying to resume
[  248.279584] [drm] PCIE GART of 512M enabled (table at 0x00F40090).
[  248.279639] [drm:amdgpu_device_gpu_recover [amdgpu]] *ERROR* VRAM is lost!
[  248.279769] [drm] PSP is resuming...
[  248.428305] [drm] reserve 0x40 from 0xf400d0 for PSP TMR SIZE
[  248.472774] WARNING: CPU: 23 PID: 21634 at
/build/linux-uQJ2um/linux-4.15.0/kernel/kthread.c:498 kthread_park+0x67/0x80
[  248.472775] Modules linked in: ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs
msr nls_utf8 cifs ccm fscache cmac bnep binfmt_misc nls_iso8859_1 edac_mce_amd
arc4 snd_hda_codec_realtek snd_hda_codec_generic kvm_amd snd_hda_codec_hdmi kvm
snd_seq_midi irqbypass snd_hda_intel snd_seq_midi_event snd_hda_codec btusb
snd_hda_core btrtl wmi_bmof snd_rawmidi iwlmvm snd_hwdep btbcm btintel snd_pcm
snd_seq bluetooth mac80211 snd_seq_device ecdh_generic snd_timer iwlwifi ccp
snd cfg80211 soundcore k10temp shpchp mac_hid sch_fq_codel ib_iser rdma_cm
iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
nct6775 hwmon_vid parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor
async_tx xor raid6_pq libcrc32c raid1
[  248.472823]  multipath linear raid0 amdgpu(OE) amdchash(OE) amdttm(OE)
amd_sched(OE) mxm_wmi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc
aesni_intel aes_x86_64 amdkcl(OE) crypto_simd glue_helper amd_iommu_v2 cryptd
drm_kms_helper syscopyarea sysfillrect sysimgblt igb fb_sys_fops drm dca nvme
i2c_algo_bit i2c_piix4 nvme_core ptp ahci atlantic libahci pps_core gpio_amdpt
wmi gpio_generic
[  248.472846] CPU: 23 PID: 21634 Comm: a.out Tainted: G   OE   
4.15.0-45-generic #48-Ubuntu
[  248.472847] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./X399 Professional Gaming, BIOS P3.30 08/14/2018
[  248.472849] RIP: 0010:kthread_park+0x67/0x80
[  248.472850] RSP: 0018:b44fc7e27ad0 EFLAGS: 00010202
[  248.472852] RAX: 0004 RBX: 9ec63f49e480 RCX:

[  248.472853] RDX: 9ec63c717198 RSI: 9ec63ea0c0c0 RDI:
9ec63dd38000
[  248.472854] RBP: b44fc7e27ae0 R08: 0051 R09:

[  248.472855] R10:  R11: 0056 R12:
9ec63ea0c0c0
[  248.472855] R13: 9ec64f4f4200 R14: 9ec63c71 R15:

[  248.472857] FS:  7fd52a286c00() GS:9ec65cdc()
knlGS:
[  248.472858] CS:  0010 DS:  ES:  CR0: 80050033
[  248.472859] CR2: 7f0c07687a98 CR3: 00081b5b6000 CR4:
003406e0
[  248.472860] Call Trace:
[  248.472865]  amddrm_sched_entity_fini+0x44/0x1b0 [amd_sched]
[  248.472868]  amddrm_sched_entity_destroy+0x1f/0x30 [amd_sched]
[  248.472907]  amdgpu_vm_fini+0xbb/0x4f0 [amdgpu]
[  248.472942]  amdgpu_driver_postclose_kms+0x15b/0x2b0 [amdgpu]
[  248.472952]  drm_release+0x26b/0x390 [drm]
[  248.472955]  __fput+0xea/0x220
[  248.472957]  fput+0xe/0x10
[  248.472959]  task_work_run+0x9d/0xc0
[  248.472961]  do_exit+0x2ec/0xb40
[  248.472963]  do_group_exit+0x43/0xb0
[  248.472965]  get_signal+0x27b/0x590
[  248.472968]  do_signal+0x37/0x730
[  248.472971]  ? __switch_to_asm+0x34/0x70
[  248.472973]  ? __switch_to_asm+0x40/0x70
[  248.472976]  ? do_vfs_ioctl+0xa8/0x630
[  248.472978]  ? __schedule+0x299/0x8a0
[  248.472980]  exit_to_usermode_loop+0x73/0xd0
[  248.472982]  do_syscall_64+0x115/0x130
[  248.472984]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[  248.472986] RIP: 0033:0x7fd528bdd5d7
[  248.472987] RSP: 002b:7ffe830d4778 EFLAGS: 

Re: [PATCH v6 1/2] drm/sched: Refactor ring mirror list handling.

[Grodzovsky, Andrey]

On 3/12/19 3:43 AM, Tomeu Vizoso wrote:
> On Thu, 27 Dec 2018 at 20:28, Andrey Grodzovsky
>  wrote:
>> Decauple sched threads stop and start and ring mirror
>> list handling from the policy of what to do about the
>> guilty jobs.
>> When stoppping the sched thread and detaching sched fences
>> from non signaled HW fenes wait for all signaled HW fences
>> to complete before rerunning the jobs.
>>
>> v2: Fix resubmission of guilty job into HW after refactoring.
>>
>> v4:
>> Full restart for all the jobs, not only from guilty ring.
>> Extract karma increase into standalone function.
>>
>> v5:
>> Rework waiting for signaled jobs without relying on the job
>> struct itself as those might already be freed for non 'guilty'
>> job's schedulers.
>> Expose karma increase to drivers.
>>
>> v6:
>> Use list_for_each_entry_safe_continue and drm_sched_process_job
>> in case fence already signaled.
>> Call drm_sched_increase_karma only once for amdgpu and add documentation.
>>
>> Suggested-by: Christian Koenig 
>> Signed-off-by: Andrey Grodzovsky 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  20 ++-
>>   drivers/gpu/drm/etnaviv/etnaviv_sched.c|  11 +-
>>   drivers/gpu/drm/scheduler/sched_main.c | 195 
>> +++--
>>   drivers/gpu/drm/v3d/v3d_sched.c|  12 +-
>>   include/drm/gpu_scheduler.h|   8 +-
>>   5 files changed, 157 insertions(+), 89 deletions(-)
>>
> [snip]
>> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c 
>> b/drivers/gpu/drm/v3d/v3d_sched.c
>> index 445b2ef..f76d9ed 100644
>> --- a/drivers/gpu/drm/v3d/v3d_sched.c
>> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
>> @@ -178,18 +178,22 @@ v3d_job_timedout(struct drm_sched_job *sched_job)
>>  for (q = 0; q < V3D_MAX_QUEUES; q++) {
>>  struct drm_gpu_scheduler *sched = &v3d->queue[q].sched;
>>
>> -   kthread_park(sched->thread);
>> -   drm_sched_hw_job_reset(sched, (sched_job->sched == sched ?
>> +   drm_sched_stop(sched, (sched_job->sched == sched ?
>> sched_job : NULL));
>> +
>> +   if(sched_job)
>> +   drm_sched_increase_karma(sched_job);
>>  }
>>
>>  /* get the GPU back into the init state */
>>  v3d_reset(v3d);
>>
>> +   for (q = 0; q < V3D_MAX_QUEUES; q++)
>> +   drm_sched_resubmit_jobs(sched_job->sched);
> Hi Andrey,
>
> I'm not sure of what was the original intent, but I guess it wasn't to
> repeatedly call resubmit_jobs on that specific job's queue?
>
> Regards,
>
> Tomeu

My bad,  there is also another mistake here with increasing karma for 
the guilty job's entity multiple times. I will fix that. Thanks for 
pointing out.

Andrey


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] gpu: drm: atomic_helper: Fix spelling errors

[Ville Syrjälä]

On Tue, Mar 12, 2019 at 12:33:07AM +, Kieran Bingham wrote:
> Trivial fixes identified while working on the DRM code.
> 
>   s/artifically/artificially/
>   s/achive/achieve/
> 
> Signed-off-by: Kieran Bingham 
> ---
> 
> v2: - Actually spell achieve correctly!

drm convention is to put this above the --- so that it gets included in
the commit msg.

With that
Reviewed-by: Ville Syrjälä 

> 
>  drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 540a77a2ade9..2453678d1186 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1752,7 +1752,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>*
>* NOTE: Commit work has multiple phases, first hardware commit, then
>* cleanup. We want them to overlap, hence need system_unbound_wq to
> -  * make sure work items don't artifically stall on each another.
> +  * make sure work items don't artificially stall on each another.
>*/
>  
>   drm_atomic_state_get(state);
> @@ -1786,7 +1786,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit);
>   *
>   * Asynchronous workers need to have sufficient parallelism to be able to run
>   * different atomic commits on different CRTCs in parallel. The simplest way 
> to
> - * achive this is by running them on the &system_unbound_wq work queue. Note
> + * achieve this is by running them on the &system_unbound_wq work queue. Note
>   * that drivers are not required to split up atomic commits and run an
>   * individual commit in parallel - userspace is supposed to do that if it 
> cares.
>   * But it might be beneficial to do that for modesets, since those 
> necessarily
> -- 
> 2.19.1

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/9] drm/bridge: tc358767: Simplify polling in tc_link_training()

[Laurent Pinchart]

Hi Andrey,

On Mon, Mar 11, 2019 at 11:26:20AM -0700, Andrey Smirnov wrote:
> On Mon, Mar 4, 2019 at 4:30 AM Laurent Pinchart wrote:
> > On Tue, Feb 26, 2019 at 11:36:05AM -0800, Andrey Smirnov wrote:
> >> Replace explicit polling in tc_link_training() with equivalent call to
> >> regmap_read_poll_timeout() for simplicity. No functional change
> >> intended (not including slightly altered debug output).
> >>
> >> Signed-off-by: Andrey Smirnov 
> >> Cc: Archit Taneja 
> >> Cc: Andrzej Hajda 
> >> Cc: Laurent Pinchart 
> >> Cc: Chris Healy 
> >> Cc: Lucas Stach 
> >> Cc: dri-devel@lists.freedesktop.org
> >> Cc: linux-ker...@vger.kernel.org
> >> ---
> >>  drivers/gpu/drm/bridge/tc358767.c | 14 +-
> >>  1 file changed, 5 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> >> b/drivers/gpu/drm/bridge/tc358767.c
> >> index 6455e6484722..ea30cec4a0c3 100644
> >> --- a/drivers/gpu/drm/bridge/tc358767.c
> >> +++ b/drivers/gpu/drm/bridge/tc358767.c
> >> @@ -735,7 +735,6 @@ static int tc_link_training(struct tc_data *tc, int 
> >> pattern)
> >>   const char * const *errors;
> >>   u32 srcctrl = tc_srcctrl(tc) | DP0_SRCCTRL_SCRMBLDIS |
> >> DP0_SRCCTRL_AUTOCORRECT;
> >> - int timeout;
> >>   int retry;
> >>   u32 value;
> >>   int ret;
> >> @@ -765,20 +764,17 @@ static int tc_link_training(struct tc_data *tc, int 
> >> pattern)
> >>   tc_write(DP0CTL, DP_EN);
> >>
> >>   /* wait */
> >> - timeout = 1000;
> >> - do {
> >> - tc_read(DP0_LTSTAT, &value);
> >> - udelay(1);
> >> - } while ((!(value & LT_LOOPDONE)) && (--timeout));
> >> - if (timeout == 0) {
> >> + ret = regmap_read_poll_timeout(tc->regmap, DP0_LTSTAT, value,
> >> +value & LT_LOOPDONE, 1, 1000);
> >> + if (ret) {
> >>   dev_err(tc->dev, "Link training timeout!\n");
> >>   } else {
> >>   int pattern = (value >> 11) & 0x3;
> >>   int error = (value >> 8) & 0x7;
> >>
> >>   dev_dbg(tc->dev,
> >> - "Link training phase %d done after %d uS: 
> >> %s\n",
> >> - pattern, 1000 - timeout, errors[error]);
> >> + "Link training phase %d done: %s\n",
> >> + pattern, errors[error]);
> >
> > It's probably not a big deal in this specific case, but in general it
> > can be useful to know how long the poll took.
> 
> I don't disagree, but bear in mind that the way time is measured in
> original loop assumes that tc_read, an I2C transaction over 100KHz
> bus, takes insignificant amount of time compared to 1 uS delay. I
> think original debug statement does a bit of a false advertising when
> it presents a number of polling loop iterations as if it is time it
> took to establish a link in microseconds.
> 
> > Any hope to enhance regmap_read_poll_timeout() to return either the elapsed 
> > time or the
> > remaining timeout instead of 0 on success ?
> 
> I'd rather not go there. That'll take convincing Mark Brown to accept
> that semantics change, then fixing all of the callers across the tree
> via a separate patch series.
> 
> What if instead we just add an extra debug statement before link
> training starts, so that duration of the process can be discerned from
> logging timestamps? This does require user doing a bit of math by
> hand, but it's actually more accurate timing info compared to original
> and it doesn't require any API modification.

That works for me.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109206

--- Comment #27 from JerryD  ---
I am following 7 serious bug reports on kernel, redhat, freedesktop bugzillas.
This one is by far the most critical when one can not boot the machine. I am
happy to try to test things. I am not set up to compile a kernel, but I can try
release candidates. If anyone sees something that might work, please let me
know.

model name  : AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx

Command line: BOOT_IMAGE=/vmlinuz-4.19.15-300.fc29.x86_64
root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap
rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_US.UTF-8
idle=nomwait iommu=pt processor.max_cstate=1

DMI: HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.20 12/25/2018

-- 
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 v5 16/19] drm: rcar-du: Fix rcar_du_crtc structure documentation

[Laurent Pinchart]

Hi Kieran,

On Mon, Mar 11, 2019 at 10:57:15PM +, Kieran Bingham wrote:
> On 21/02/2019 10:32, Laurent Pinchart wrote:
> > The rcar_du_crtc structure index field contains the CRTC hardware index,
> > not the hardware and software index. Update the documentation
> > accordingly.
> 
> Should this have a fixes tag? It's only trivial - but if so:
> 
> Fixes: 5361cc7f8e91 ("drm: rcar-du: Split CRTC handling to support
> hardware indexing")

I'll add it for correctness, I just hope it won't be automatically
backported to stable.

> Either way,
> 
> Reviewed-by: Kieran Bingham 
> 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > index bcb35b0b7612..c478953be092 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > @@ -27,7 +27,7 @@ struct rcar_du_vsp;
> >   * @clock: the CRTC functional clock
> >   * @extclock: external pixel dot clock (optional)
> >   * @mmio_offset: offset of the CRTC registers in the DU MMIO block
> > - * @index: CRTC software and hardware index
> > + * @index: CRTC hardware index
> >   * @initialized: whether the CRTC has been initialized and clocks enabled
> >   * @dsysr: cached value of the DSYSR register
> >   * @vblank_enable: whether vblank events are enabled on this CRTC

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/5] drm/rockchip: fix fb references in async update

[Helen Koike]

On 3/12/19 3:34 AM, Boris Brezillon wrote:
> On Mon, 11 Mar 2019 23:21:59 -0300
> Helen Koike  wrote:
> 
>> In the case of async update, modifications are done in place, i.e. in the
>> current plane state, so the new_state is prepared and the new_state is
>> cleanup up (instead of the old_state, diferrently on what happen in a
> 
>   ^ cleaned up^ differently (but maybe
> "unlike what happens" is more appropriate here).
> 
>> normal sync update).
>> To cleanup the old_fb properly, it needs to be placed in the new_state
>> in the end of async_update, so cleanup call will unreference the old_fb
>> correctly.
>>
>> Also, the previous code had a:
>>
>>  plane_state = plane->funcs->atomic_duplicate_state(plane);
>>  ...
>>  swap(plane_state, plane->state);
>>
>>  if (plane->state->fb && plane->state->fb != new_state->fb) {
>>  ...
>>  }
>>
>> Which was wrong, as the fb were just assigned to be equal, so this if
>> statement nevers evaluates to true.
>>
>> Another details is that the function drm_crtc_vblank_get() can only be
>> called when vop->is_enabled is true, otherwise it has no effect and
>> trows a WARN_ON().
>>
>> Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
>> fb and pus the old fb) is not required, as it is taken care by
>> drm_mode_cursor_universal() when calling
>> drm_atomic_helper_update_plane().
>>
>> Signed-off-by: Helen Koike 
>>
>> ---
>> Hello,
>>
>> I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
>> kms_cursor_legacy and I didn't see any regressions.
>>
>> Changes in v2: None
>>
>>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 -
>>  1 file changed, 24 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index c7d4c6073ea5..a1ee8c156a7b 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -912,30 +912,31 @@ static void vop_plane_atomic_async_update(struct 
>> drm_plane *plane,
>>struct drm_plane_state *new_state)
>>  {
>>  struct vop *vop = to_vop(plane->state->crtc);
>> -struct drm_plane_state *plane_state;
>> +struct drm_framebuffer *old_fb = plane->state->fb;
>>  
>> -plane_state = plane->funcs->atomic_duplicate_state(plane);
>> -plane_state->crtc_x = new_state->crtc_x;
>> -plane_state->crtc_y = new_state->crtc_y;
>> -plane_state->crtc_h = new_state->crtc_h;
>> -plane_state->crtc_w = new_state->crtc_w;
>> -plane_state->src_x = new_state->src_x;
>> -plane_state->src_y = new_state->src_y;
>> -plane_state->src_h = new_state->src_h;
>> -plane_state->src_w = new_state->src_w;
>> -
>> -if (plane_state->fb != new_state->fb)
>> -drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
>> -
>> -swap(plane_state, plane->state);
>> -
>> -if (plane->state->fb && plane->state->fb != new_state->fb) {
>> +/*
>> + * A scanout can still be occurring, so we can't drop the reference to
>> + * the old framebuffer. To solve this we get a reference to old_fb and
>> + * set a worker to release it later.
> 
> Hm, doesn't look like an async update to me if we have to wait for the
> next VBLANK to happen to get the new content on the screen. Maybe we
> should reject async updates when old_fb != new_fb in the rk
> ->async_check() hook.

Unless I am misunderstanding this, we don't wait here, we just grab a
reference to the fb in case it is being still used by the hw, so it
doesn't get released prematurely.

> 
>> + */
>> +if (vop->is_enabled &&
>> +plane->state->fb && plane->state->fb != new_state->fb) {
>>  drm_framebuffer_get(plane->state->fb);
>>  WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
>>  drm_flip_work_queue(&vop->fb_unref_work, plane->state->fb);
>>  set_bit(VOP_PENDING_FB_UNREF, &vop->pending);
>>  }
> 
> In any case, I think this should be called after
> vop_plane_atomic_update() to prevent the situation where the VBLANK
> event happens between this point and the following
> vop_plane_atomic_update() call.

ack, I'll update it in the next version.

> 
>>  
>> +plane->state->crtc_x = new_state->crtc_x;
>> +plane->state->crtc_y = new_state->crtc_y;
>> +plane->state->crtc_h = new_state->crtc_h;
>> +plane->state->crtc_w = new_state->crtc_w;
>> +plane->state->src_x = new_state->src_x;
>> +plane->state->src_y = new_state->src_y;
>> +plane->state->src_h = new_state->src_h;
>> +plane->state->src_w = new_state->src_w;
>> +plane->state->fb = new_state->fb;
> 
> Any reason not to use swap() here and reference plane->state->fb
> instead of new_state->fb after this point?

I had the impression I had to do this in one of my tests, but re-testing
now and re-looking at the code this doesn't seem to

Re: [PATCH v2] drm/fourcc: add ARM GPU tile format

[Ayan Halder]

On Mon, Mar 11, 2019 at 09:39:28AM -0700, Alyssa Rosenzweig wrote:
> > You might want to re-use the exisiting modifier
> > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16.
> > 
> > I would suggest you to have a look at the exisiting AFBC modifiers
> > (denoted by AFBC_FORMAT_MOD_XXX ) and let us know if there is
> > something you cannot reuse.
> 
> So, the "tiled" format in question (that Qiang needs to import/export
> BOs in) is *uncompressed* but tiled with an Arm-internal format (for the
> GPUs).  Here's a software implementation for encoding this format:
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/panfrost/pan_swizzle.c
>
ok I understood now. In this case, please ignore my suggestion.
 
> For Midgard/Bifrost, we use this tiling internally for uploading bitmap
> textures, but we only render to AFBC (or linear). So for Panfrost, we'll
> always be importing/exporting AFBC buffers, never uncompressed tiled.

I am not a gpu guy so can't comment at the moment.

> But Utgard does not seem to support AFBC (?), so Qiang needs the
> uncompressed tiled for the same purpose Panfrost uses AFBC.
> 
> Is it possible that this is the same tiling used internally by
> AFBC_FORMAT_MOD_BLOCK_SIZE_16x16, only without any compression? AFBC is
> blackbox for us, so this isn't something we can figure out ourselves,
> but that influences whether it's appropriate to reuse the modifier. If
> this is the same tiling scheme, perhaps that's the answer. If it's not
> (I don't know how AFBC tiling works), we probably do need a separate
> modifier to avoid confusion.
>
AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 denotes the superblock size to be
used only in case of AFBC buffers.
For non compressed tiled format, none of the AFBC_FORMAT_MOD_XXX
should be used.

However, I would like you to review my patch series
(https://patchwork.freedesktop.org/series/53395/) to
see if we have the same understanding.
 
> Thanks,
> 
> Alyssa



> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/5] drm/rockchip: fix fb references in async update

[Boris Brezillon]

On Tue, 12 Mar 2019 12:34:45 -0300
Helen Koike  wrote:

> On 3/12/19 3:34 AM, Boris Brezillon wrote:
> > On Mon, 11 Mar 2019 23:21:59 -0300
> > Helen Koike  wrote:
> >   
> >> In the case of async update, modifications are done in place, i.e. in the
> >> current plane state, so the new_state is prepared and the new_state is
> >> cleanup up (instead of the old_state, diferrently on what happen in a  
> > 
> >   ^ cleaned up  ^ differently (but maybe
> > "unlike what happens" is more appropriate here).
> >   
> >> normal sync update).
> >> To cleanup the old_fb properly, it needs to be placed in the new_state
> >> in the end of async_update, so cleanup call will unreference the old_fb
> >> correctly.
> >>
> >> Also, the previous code had a:
> >>
> >>plane_state = plane->funcs->atomic_duplicate_state(plane);
> >>...
> >>swap(plane_state, plane->state);
> >>
> >>if (plane->state->fb && plane->state->fb != new_state->fb) {
> >>...
> >>}
> >>
> >> Which was wrong, as the fb were just assigned to be equal, so this if
> >> statement nevers evaluates to true.
> >>
> >> Another details is that the function drm_crtc_vblank_get() can only be
> >> called when vop->is_enabled is true, otherwise it has no effect and
> >> trows a WARN_ON().
> >>
> >> Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
> >> fb and pus the old fb) is not required, as it is taken care by
> >> drm_mode_cursor_universal() when calling
> >> drm_atomic_helper_update_plane().
> >>
> >> Signed-off-by: Helen Koike 
> >>
> >> ---
> >> Hello,
> >>
> >> I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
> >> kms_cursor_legacy and I didn't see any regressions.
> >>
> >> Changes in v2: None
> >>
> >>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 -
> >>  1 file changed, 24 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> >> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >> index c7d4c6073ea5..a1ee8c156a7b 100644
> >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >> @@ -912,30 +912,31 @@ static void vop_plane_atomic_async_update(struct 
> >> drm_plane *plane,
> >>  struct drm_plane_state *new_state)
> >>  {
> >>struct vop *vop = to_vop(plane->state->crtc);
> >> -  struct drm_plane_state *plane_state;
> >> +  struct drm_framebuffer *old_fb = plane->state->fb;
> >>  
> >> -  plane_state = plane->funcs->atomic_duplicate_state(plane);
> >> -  plane_state->crtc_x = new_state->crtc_x;
> >> -  plane_state->crtc_y = new_state->crtc_y;
> >> -  plane_state->crtc_h = new_state->crtc_h;
> >> -  plane_state->crtc_w = new_state->crtc_w;
> >> -  plane_state->src_x = new_state->src_x;
> >> -  plane_state->src_y = new_state->src_y;
> >> -  plane_state->src_h = new_state->src_h;
> >> -  plane_state->src_w = new_state->src_w;
> >> -
> >> -  if (plane_state->fb != new_state->fb)
> >> -  drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
> >> -
> >> -  swap(plane_state, plane->state);
> >> -
> >> -  if (plane->state->fb && plane->state->fb != new_state->fb) {
> >> +  /*
> >> +   * A scanout can still be occurring, so we can't drop the reference to
> >> +   * the old framebuffer. To solve this we get a reference to old_fb and
> >> +   * set a worker to release it later.  
> > 
> > Hm, doesn't look like an async update to me if we have to wait for the
> > next VBLANK to happen to get the new content on the screen. Maybe we
> > should reject async updates when old_fb != new_fb in the rk  
> > ->async_check() hook.  
> 
> Unless I am misunderstanding this, we don't wait here, we just grab a
> reference to the fb in case it is being still used by the hw, so it
> doesn't get released prematurely.

I was just reacting to the comment that says the new FB should stay
around until the next VBLANK event happens. If the FB must stay around
that probably means the HW is still using, which made me wonder if this
HW actually supports async update (where async means "update now and
don't care about about tearing"). Or maybe it takes some time to switch
to the new FB and waiting for the next VBLANK to release the old FB was
an easy solution to not wait for the flip to actually happen in
->async_update() (which is kind of a combination of async+non-blocking).

Anyway, let's keep it like that.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] gpu: drm: atomic_helper: Fix spelling errors

[Kieran Bingham]

Hi Ville,

On 12/03/2019 15:14, Ville Syrjälä wrote:
> On Tue, Mar 12, 2019 at 12:33:07AM +, Kieran Bingham wrote:
>> Trivial fixes identified while working on the DRM code.
>>
>>   s/artifically/artificially/
>>   s/achive/achieve/
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>
>> v2: - Actually spell achieve correctly!
> 
> drm convention is to put this above the --- so that it gets included in
> the commit msg.

Oh - in linux-media these are just dropped.

I'll try to remember this for my future work in DRM.

I don't have commit access anyway, so can I presume whomever will pick
this up will adjust if necessary?

Or should I repost? (which might be a bit redundant just to move a patch
version comment which would then increase again :D )


> With that
> Reviewed-by: Ville Syrjälä 

Thanks,
--
Regards

Kieran


> 
>>
>>  drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 540a77a2ade9..2453678d1186 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -1752,7 +1752,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>>   *
>>   * NOTE: Commit work has multiple phases, first hardware commit, then
>>   * cleanup. We want them to overlap, hence need system_unbound_wq to
>> - * make sure work items don't artifically stall on each another.
>> + * make sure work items don't artificially stall on each another.
>>   */
>>  
>>  drm_atomic_state_get(state);
>> @@ -1786,7 +1786,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit);
>>   *
>>   * Asynchronous workers need to have sufficient parallelism to be able to 
>> run
>>   * different atomic commits on different CRTCs in parallel. The simplest 
>> way to
>> - * achive this is by running them on the &system_unbound_wq work queue. Note
>> + * achieve this is by running them on the &system_unbound_wq work queue. 
>> Note
>>   * that drivers are not required to split up atomic commits and run an
>>   * individual commit in parallel - userspace is supposed to do that if it 
>> cares.
>>   * But it might be beneficial to do that for modesets, since those 
>> necessarily
>> -- 
>> 2.19.1
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/5] drm/bridge: sii902x: Implement HDMI audio support

[Rob Herring]

On Wed, Feb 27, 2019 at 11:54:23PM +0200, Jyri Sarha wrote:
> Implement HDMI audio support by using ASoC HDMI codec. The commit
> implements the necessary callbacks and configuration for the HDMI
> codec and registers a virtual platform device for the codec to attach.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  .../bindings/display/bridge/sii902x.txt   |  36 +-
>  drivers/gpu/drm/bridge/sii902x.c  | 453 +-
>  include/dt-bindings/sound/sii902x-audio.h |  11 +

Please split bindings (doc and header) to a separate patch.

>  3 files changed, 493 insertions(+), 7 deletions(-)
>  create mode 100644 include/dt-bindings/sound/sii902x-audio.h
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt 
> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> index 72d2dc6c3e6b..647b2fd84db9 100644
> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> @@ -5,9 +5,32 @@ Required properties:
>   - reg: i2c address of the bridge
>  
>  Optional properties:
> - - interrupts: describe the interrupt line used to inform the host 
> + - interrupts: describe the interrupt line used to inform the host

Unrelated change.

> about hotplug events.
>   - reset-gpios: OF device-tree gpio specification for RST_N pin.
> + - i2s-fifo-routing: Array of exactly 4 integers indicating i2s

Needs a vendor prefix.

> +   pins for audio fifo routing. First integer defines routing to
> +   fifo 0 and second to fifo 1, etc. Integers can be filled with
> +   definitions from: include/dt-bindings/sound/sii902x-audio.h
> +   The available definitions are:
> +   - ENABLE_BIT: enable this audio fifo
> +   - CONNECT_SD#: route audio input from SD0, SD1, SD2, or SD3 i2s
> +  data input pin
> +   - LEFT_RIGHT_SWAP_BIT: swap i2s input channels for this fifo
> +   I2S HDMI audio is configured only if this property is found.
> + - clocks: phandle mclk
> + - clock-names: "mclk"
> + Describes SII902x MCLK input. MCLK is used to produce
> + HDMI audio CTS values. This property is required if
> + "i2s-fifo-routing"-property is present. This property follows
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + consumer binding.
> + - #sound-dai-cells = <0>: ASoC codec dai available for simple-card
> + If audio properties are present sii902x provides an ASoC
> + codec component driver that can be used by other ASoC
> + components like simple-card. See binding document fo> + 
> details:
> + Documentation/devicetree/bindings/sound/simple-card.txt
>  
>  Optional subnodes:
>   - video input: this subnode can contain a video input port node
> @@ -21,6 +44,17 @@ Example:
>   compatible = "sil,sii9022";
>   reg = <0x39>;
>   reset-gpios = <&pioA 1 0>;
> +
> + #sound-dai-cells = <0>;
> + i2s-fifo-routing = <
> + (ENABLE_BIT|CONNECT_SD0)
> + 0
> + 0
> + 0
> + >;
> + clocks = <&mclk>;
> + clock-names = "mclk";
> +
>   ports {
>   #address-cells = <1>;
>   #size-cells = <0>;

[...]

> diff --git a/include/dt-bindings/sound/sii902x-audio.h 
> b/include/dt-bindings/sound/sii902x-audio.h
> new file mode 100644
> index ..32e50a926b6f
> --- /dev/null
> +++ b/include/dt-bindings/sound/sii902x-audio.h
> @@ -0,0 +1,11 @@

License?

> +#ifndef __DT_SII9022_AUDIO_H
> +#define __DT_SII9022_AUDIO_H
> +
> +#define ENABLE_BIT   0x80
> +#define CONNECT_SD0  0x00
> +#define CONNECT_SD1  0x10
> +#define CONNECT_SD2  0x20
> +#define CONNECT_SD3  0x30
> +#define LEFT_RIGHT_SWAP_BIT  0x04
> +
> +#endif /* __DT_SII9022_AUDIO_H */
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output

[Ville Syrjälä]

On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> > This adds support for outputting kernel messages on panic().
> > A kernel message dumper is used to dump the log. The dumper iterates
> > over each DRM device and it's crtc's to find suitable framebuffers.
> > 
> > All the other dumpers are run before this one except mtdoops.
> > Only atomic drivers are supported.
> > 
> > Signed-off-by: Noralf Trønnes 
> > ---
> >  [...]
> > 
> > diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
> > index f0b34c977ec5..f3274798ecfe 100644
> > --- a/include/drm/drm_framebuffer.h
> > +++ b/include/drm/drm_framebuffer.h
> > @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
> >  struct drm_file *file_priv, unsigned flags,
> >  unsigned color, struct drm_clip_rect *clips,
> >  unsigned num_clips);
> > +
> > +   /**
> > +* @panic_vmap:
> > +*
> > +* Optional callback for panic handling.
> > +*
> > +* For vmapping the selected framebuffer in a panic context. Must
> > +* be super careful about locking (only trylocking allowed).
> > +*
> > +* RETURNS:
> > +*
> > +* NULL if it didn't work out, otherwise an opaque cookie which is
> > +* passed to @panic_draw_xy. It can be anything: vmap area, structure
> > +* with more details, just a few flags, ...
> > +*/
> > +   void *(*panic_vmap)(struct drm_framebuffer *fb);
> 
> FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
> drivers:
> 
> Framebuffers are normally tiled, writing to them with the CPU results in
> garbled output.
> 
> With a discrete GPU having a large amount of VRAM, the framebuffer may
> not be directly CPU accessible at all.
> 
> 
> There would need to be a mechanism for switching scanout to a linear,
> CPU accessible framebuffer.

I suppose panic_vmap() could just provide a linear temp buffer
to the panic handler, and panic_unmap() could copy the contents
over to the real fb.

That said, this approach of scribbling over the primary plane's
framebuffer has some clear limitations:
* something may overwrite the oops message before the user
  can even read it
* there may be other planes obscuring part or all of the
  primary plane

Also scribbling over the user's framebuffer seems rather rude
to me, so I'm thinking this approach should be limited to kernel
panics only.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/v3d: Fix calling drm_sched_resubmit_jobs for same sched.

[Andrey Grodzovsky]

Also stop calling drm_sched_increase_karma multiple times.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/v3d/v3d_sched.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 4704b2d..ce7c737b 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -231,20 +231,17 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct 
drm_sched_job *sched_job)
mutex_lock(&v3d->reset_lock);
 
/* block scheduler */
-   for (q = 0; q < V3D_MAX_QUEUES; q++) {
-   struct drm_gpu_scheduler *sched = &v3d->queue[q].sched;
-
-   drm_sched_stop(sched);
+   for (q = 0; q < V3D_MAX_QUEUES; q++)
+   drm_sched_stop(&v3d->queue[q].sched);
 
-   if(sched_job)
-   drm_sched_increase_karma(sched_job);
-   }
+   if(sched_job)
+   drm_sched_increase_karma(sched_job);
 
/* get the GPU back into the init state */
v3d_reset(v3d);
 
for (q = 0; q < V3D_MAX_QUEUES; q++)
-   drm_sched_resubmit_jobs(sched_job->sched);
+   drm_sched_resubmit_jobs(&v3d->queue[q].sched);
 
/* Unblock schedulers and restart their jobs. */
for (q = 0; q < V3D_MAX_QUEUES; q++) {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5.0 13/25] drm: disable uncached DMA optimization for ARM and arm64

[Greg Kroah-Hartman]

5.0-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]

The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
for some buffers, both the CPU and the GPU use uncached mappings,
removing the need for DMA snooping and allocation in the CPU caches.

The use of uncached GPU mappings relies on the correct implementation
of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
will use cached mappings nonetheless. On x86 platforms, this does not
seem to matter, as uncached CPU mappings will snoop the caches in any
case. However, on ARM and arm64, enabling this optimization on a
platform where NoSnoop is ignored results in loss of coherency, which
breaks correct operation of the device. Since we have no way of
detecting whether NoSnoop works or not, just disable this
optimization entirely for ARM and arm64.

Cc: Christian Koenig 
Cc: Alex Deucher 
Cc: David Zhou 
Cc: Huang Rui 
Cc: Junwei Zhang 
Cc: Michel Daenzer 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Will Deacon 
Cc: Christoph Hellwig 
Cc: Robin Murphy 
Cc: amd-gfx list 
Cc: dri-devel 
Reported-by: Carsten Haitzler 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Christian König 
Reviewed-by: Alex Deucher 
Link: https://patchwork.kernel.org/patch/10778815/
Signed-off-by: Christian König 
Signed-off-by: Sasha Levin 
---
 include/drm/drm_cache.h |   18 ++
 1 file changed, 18 insertions(+)

--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -47,6 +47,24 @@ static inline bool drm_arch_can_wc_memor
return false;
 #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3)
return false;
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   /*
+* The DRM driver stack is designed to work with cache coherent devices
+* only, but permits an optimization to be enabled in some cases, where
+* for some buffers, both the CPU and the GPU use uncached mappings,
+* removing the need for DMA snooping and allocation in the CPU caches.
+*
+* The use of uncached GPU mappings relies on the correct implementation
+* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
+* will use cached mappings nonetheless. On x86 platforms, this does not
+* seem to matter, as uncached CPU mappings will snoop the caches in any
+* case. However, on ARM and arm64, enabling this optimization on a
+* platform where NoSnoop is ignored results in loss of coherency, which
+* breaks correct operation of the device. Since we have no way of
+* detecting whether NoSnoop works or not, just disable this
+* optimization entirely for ARM and arm64.
+*/
+   return false;
 #else
return true;
 #endif


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4.20 160/171] drm: disable uncached DMA optimization for ARM and arm64

[Greg Kroah-Hartman]

4.20-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]

The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
for some buffers, both the CPU and the GPU use uncached mappings,
removing the need for DMA snooping and allocation in the CPU caches.

The use of uncached GPU mappings relies on the correct implementation
of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
will use cached mappings nonetheless. On x86 platforms, this does not
seem to matter, as uncached CPU mappings will snoop the caches in any
case. However, on ARM and arm64, enabling this optimization on a
platform where NoSnoop is ignored results in loss of coherency, which
breaks correct operation of the device. Since we have no way of
detecting whether NoSnoop works or not, just disable this
optimization entirely for ARM and arm64.

Cc: Christian Koenig 
Cc: Alex Deucher 
Cc: David Zhou 
Cc: Huang Rui 
Cc: Junwei Zhang 
Cc: Michel Daenzer 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Will Deacon 
Cc: Christoph Hellwig 
Cc: Robin Murphy 
Cc: amd-gfx list 
Cc: dri-devel 
Reported-by: Carsten Haitzler 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Christian König 
Reviewed-by: Alex Deucher 
Link: https://patchwork.kernel.org/patch/10778815/
Signed-off-by: Christian König 
Signed-off-by: Sasha Levin 
---
 include/drm/drm_cache.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index bfe1639df02d..97fc498dc767 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -47,6 +47,24 @@ static inline bool drm_arch_can_wc_memory(void)
return false;
 #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3)
return false;
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   /*
+* The DRM driver stack is designed to work with cache coherent devices
+* only, but permits an optimization to be enabled in some cases, where
+* for some buffers, both the CPU and the GPU use uncached mappings,
+* removing the need for DMA snooping and allocation in the CPU caches.
+*
+* The use of uncached GPU mappings relies on the correct implementation
+* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
+* will use cached mappings nonetheless. On x86 platforms, this does not
+* seem to matter, as uncached CPU mappings will snoop the caches in any
+* case. However, on ARM and arm64, enabling this optimization on a
+* platform where NoSnoop is ignored results in loss of coherency, which
+* breaks correct operation of the device. Since we have no way of
+* detecting whether NoSnoop works or not, just disable this
+* optimization entirely for ARM and arm64.
+*/
+   return false;
 #else
return true;
 #endif
-- 
2.19.1



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output

[Noralf Trønnes]

Den 12.03.2019 17.17, skrev Ville Syrjälä:
> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
>> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
>>> This adds support for outputting kernel messages on panic().
>>> A kernel message dumper is used to dump the log. The dumper iterates
>>> over each DRM device and it's crtc's to find suitable framebuffers.
>>>
>>> All the other dumpers are run before this one except mtdoops.
>>> Only atomic drivers are supported.
>>>
>>> Signed-off-by: Noralf Trønnes 
>>> ---
>>>  [...]
>>>
>>> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
>>> index f0b34c977ec5..f3274798ecfe 100644
>>> --- a/include/drm/drm_framebuffer.h
>>> +++ b/include/drm/drm_framebuffer.h
>>> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
>>>  struct drm_file *file_priv, unsigned flags,
>>>  unsigned color, struct drm_clip_rect *clips,
>>>  unsigned num_clips);
>>> +
>>> +   /**
>>> +* @panic_vmap:
>>> +*
>>> +* Optional callback for panic handling.
>>> +*
>>> +* For vmapping the selected framebuffer in a panic context. Must
>>> +* be super careful about locking (only trylocking allowed).
>>> +*
>>> +* RETURNS:
>>> +*
>>> +* NULL if it didn't work out, otherwise an opaque cookie which is
>>> +* passed to @panic_draw_xy. It can be anything: vmap area, structure
>>> +* with more details, just a few flags, ...
>>> +*/
>>> +   void *(*panic_vmap)(struct drm_framebuffer *fb);
>>
>> FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
>> drivers:
>>
>> Framebuffers are normally tiled, writing to them with the CPU results in
>> garbled output.
>>

In which case the driver needs to support the ->panic_draw_xy callback,
or maybe it's possible to make a generic helper for tiled buffers.

>> With a discrete GPU having a large amount of VRAM, the framebuffer may
>> not be directly CPU accessible at all.
>>

I would have been nice to know how Windows works around this.

>>
>> There would need to be a mechanism for switching scanout to a linear,
>> CPU accessible framebuffer.
> 
> I suppose panic_vmap() could just provide a linear temp buffer
> to the panic handler, and panic_unmap() could copy the contents
> over to the real fb.
> 
> That said, this approach of scribbling over the primary plane's
> framebuffer has some clear limitations:
> * something may overwrite the oops message before the user
>   can even read it

When the dumper drm_panic_kmsg_dump() runs, the other CPU's should have
been stopped. See panic().

> * there may be other planes obscuring part or all of the
>   primary plane
> 

Yeah, this is a problem, again I wonder how Windows deals with this.

> Also scribbling over the user's framebuffer seems rather rude
> to me, so I'm thinking this approach should be limited to kernel
> panics only.
> 

Yes this will only happen on kernel panics:

panic() -> kmsg_dump() -> drm_panic_kmsg_dump()

(Unless invoking through debugfs ofc)

Noralf.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4.19 134/149] drm: disable uncached DMA optimization for ARM and arm64

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]

The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
for some buffers, both the CPU and the GPU use uncached mappings,
removing the need for DMA snooping and allocation in the CPU caches.

The use of uncached GPU mappings relies on the correct implementation
of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
will use cached mappings nonetheless. On x86 platforms, this does not
seem to matter, as uncached CPU mappings will snoop the caches in any
case. However, on ARM and arm64, enabling this optimization on a
platform where NoSnoop is ignored results in loss of coherency, which
breaks correct operation of the device. Since we have no way of
detecting whether NoSnoop works or not, just disable this
optimization entirely for ARM and arm64.

Cc: Christian Koenig 
Cc: Alex Deucher 
Cc: David Zhou 
Cc: Huang Rui 
Cc: Junwei Zhang 
Cc: Michel Daenzer 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Will Deacon 
Cc: Christoph Hellwig 
Cc: Robin Murphy 
Cc: amd-gfx list 
Cc: dri-devel 
Reported-by: Carsten Haitzler 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Christian König 
Reviewed-by: Alex Deucher 
Link: https://patchwork.kernel.org/patch/10778815/
Signed-off-by: Christian König 
Signed-off-by: Sasha Levin 
---
 include/drm/drm_cache.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index bfe1639df02d..97fc498dc767 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -47,6 +47,24 @@ static inline bool drm_arch_can_wc_memory(void)
return false;
 #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3)
return false;
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   /*
+* The DRM driver stack is designed to work with cache coherent devices
+* only, but permits an optimization to be enabled in some cases, where
+* for some buffers, both the CPU and the GPU use uncached mappings,
+* removing the need for DMA snooping and allocation in the CPU caches.
+*
+* The use of uncached GPU mappings relies on the correct implementation
+* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
+* will use cached mappings nonetheless. On x86 platforms, this does not
+* seem to matter, as uncached CPU mappings will snoop the caches in any
+* case. However, on ARM and arm64, enabling this optimization on a
+* platform where NoSnoop is ignored results in loss of coherency, which
+* breaks correct operation of the device. Since we have no way of
+* detecting whether NoSnoop works or not, just disable this
+* optimization entirely for ARM and arm64.
+*/
+   return false;
 #else
return true;
 #endif
-- 
2.19.1



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4.14 127/135] drm: disable uncached DMA optimization for ARM and arm64

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]

The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
for some buffers, both the CPU and the GPU use uncached mappings,
removing the need for DMA snooping and allocation in the CPU caches.

The use of uncached GPU mappings relies on the correct implementation
of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
will use cached mappings nonetheless. On x86 platforms, this does not
seem to matter, as uncached CPU mappings will snoop the caches in any
case. However, on ARM and arm64, enabling this optimization on a
platform where NoSnoop is ignored results in loss of coherency, which
breaks correct operation of the device. Since we have no way of
detecting whether NoSnoop works or not, just disable this
optimization entirely for ARM and arm64.

Cc: Christian Koenig 
Cc: Alex Deucher 
Cc: David Zhou 
Cc: Huang Rui 
Cc: Junwei Zhang 
Cc: Michel Daenzer 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Will Deacon 
Cc: Christoph Hellwig 
Cc: Robin Murphy 
Cc: amd-gfx list 
Cc: dri-devel 
Reported-by: Carsten Haitzler 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Christian König 
Reviewed-by: Alex Deucher 
Link: https://patchwork.kernel.org/patch/10778815/
Signed-off-by: Christian König 
Signed-off-by: Sasha Levin 
---
 include/drm/drm_cache.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index beab0f0d0cfb..250e2d13c61b 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -45,6 +45,24 @@ static inline bool drm_arch_can_wc_memory(void)
return false;
 #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3)
return false;
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   /*
+* The DRM driver stack is designed to work with cache coherent devices
+* only, but permits an optimization to be enabled in some cases, where
+* for some buffers, both the CPU and the GPU use uncached mappings,
+* removing the need for DMA snooping and allocation in the CPU caches.
+*
+* The use of uncached GPU mappings relies on the correct implementation
+* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
+* will use cached mappings nonetheless. On x86 platforms, this does not
+* seem to matter, as uncached CPU mappings will snoop the caches in any
+* case. However, on ARM and arm64, enabling this optimization on a
+* platform where NoSnoop is ignored results in loss of coherency, which
+* breaks correct operation of the device. Since we have no way of
+* detecting whether NoSnoop works or not, just disable this
+* optimization entirely for ARM and arm64.
+*/
+   return false;
 #else
return true;
 #endif
-- 
2.19.1



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4.9 91/96] drm: disable uncached DMA optimization for ARM and arm64

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]

The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
for some buffers, both the CPU and the GPU use uncached mappings,
removing the need for DMA snooping and allocation in the CPU caches.

The use of uncached GPU mappings relies on the correct implementation
of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
will use cached mappings nonetheless. On x86 platforms, this does not
seem to matter, as uncached CPU mappings will snoop the caches in any
case. However, on ARM and arm64, enabling this optimization on a
platform where NoSnoop is ignored results in loss of coherency, which
breaks correct operation of the device. Since we have no way of
detecting whether NoSnoop works or not, just disable this
optimization entirely for ARM and arm64.

Cc: Christian Koenig 
Cc: Alex Deucher 
Cc: David Zhou 
Cc: Huang Rui 
Cc: Junwei Zhang 
Cc: Michel Daenzer 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Will Deacon 
Cc: Christoph Hellwig 
Cc: Robin Murphy 
Cc: amd-gfx list 
Cc: dri-devel 
Reported-by: Carsten Haitzler 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Christian König 
Reviewed-by: Alex Deucher 
Link: https://patchwork.kernel.org/patch/10778815/
Signed-off-by: Christian König 
Signed-off-by: Sasha Levin 
---
 include/drm/drm_cache.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index cebecff536a3..c5fb6f871930 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -41,6 +41,24 @@ static inline bool drm_arch_can_wc_memory(void)
return false;
 #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3)
return false;
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   /*
+* The DRM driver stack is designed to work with cache coherent devices
+* only, but permits an optimization to be enabled in some cases, where
+* for some buffers, both the CPU and the GPU use uncached mappings,
+* removing the need for DMA snooping and allocation in the CPU caches.
+*
+* The use of uncached GPU mappings relies on the correct implementation
+* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
+* will use cached mappings nonetheless. On x86 platforms, this does not
+* seem to matter, as uncached CPU mappings will snoop the caches in any
+* case. However, on ARM and arm64, enabling this optimization on a
+* platform where NoSnoop is ignored results in loss of coherency, which
+* breaks correct operation of the device. Since we have no way of
+* detecting whether NoSnoop works or not, just disable this
+* optimization entirely for ARM and arm64.
+*/
+   return false;
 #else
return true;
 #endif
-- 
2.19.1



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output

[Ville Syrjälä]

On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
> 
> 
> Den 12.03.2019 17.17, skrev Ville Syrjälä:
> > On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> >> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> >>> This adds support for outputting kernel messages on panic().
> >>> A kernel message dumper is used to dump the log. The dumper iterates
> >>> over each DRM device and it's crtc's to find suitable framebuffers.
> >>>
> >>> All the other dumpers are run before this one except mtdoops.
> >>> Only atomic drivers are supported.
> >>>
> >>> Signed-off-by: Noralf Trønnes 
> >>> ---
> >>>  [...]
> >>>
> >>> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
> >>> index f0b34c977ec5..f3274798ecfe 100644
> >>> --- a/include/drm/drm_framebuffer.h
> >>> +++ b/include/drm/drm_framebuffer.h
> >>> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
> >>>struct drm_file *file_priv, unsigned flags,
> >>>unsigned color, struct drm_clip_rect *clips,
> >>>unsigned num_clips);
> >>> +
> >>> + /**
> >>> +  * @panic_vmap:
> >>> +  *
> >>> +  * Optional callback for panic handling.
> >>> +  *
> >>> +  * For vmapping the selected framebuffer in a panic context. Must
> >>> +  * be super careful about locking (only trylocking allowed).
> >>> +  *
> >>> +  * RETURNS:
> >>> +  *
> >>> +  * NULL if it didn't work out, otherwise an opaque cookie which is
> >>> +  * passed to @panic_draw_xy. It can be anything: vmap area, structure
> >>> +  * with more details, just a few flags, ...
> >>> +  */
> >>> + void *(*panic_vmap)(struct drm_framebuffer *fb);
> >>
> >> FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
> >> drivers:
> >>
> >> Framebuffers are normally tiled, writing to them with the CPU results in
> >> garbled output.
> >>
> 
> In which case the driver needs to support the ->panic_draw_xy callback,
> or maybe it's possible to make a generic helper for tiled buffers.
> 
> >> With a discrete GPU having a large amount of VRAM, the framebuffer may
> >> not be directly CPU accessible at all.
> >>
> 
> I would have been nice to know how Windows works around this.
> 
> >>
> >> There would need to be a mechanism for switching scanout to a linear,
> >> CPU accessible framebuffer.
> > 
> > I suppose panic_vmap() could just provide a linear temp buffer
> > to the panic handler, and panic_unmap() could copy the contents
> > over to the real fb.
> > 
> > That said, this approach of scribbling over the primary plane's
> > framebuffer has some clear limitations:
> > * something may overwrite the oops message before the user
> >   can even read it
> 
> When the dumper drm_panic_kmsg_dump() runs, the other CPU's should have
> been stopped. See panic().

GPUs etc. may still be executing away.

> 
> > * there may be other planes obscuring part or all of the
> >   primary plane
> > 
> 
> Yeah, this is a problem, again I wonder how Windows deals with this.

Probably just disables all other planes. Not that it uses planes
all that heavily.

> 
> > Also scribbling over the user's framebuffer seems rather rude
> > to me, so I'm thinking this approach should be limited to kernel
> > panics only.
> > 
> 
> Yes this will only happen on kernel panics:
> 
> panic() -> kmsg_dump() -> drm_panic_kmsg_dump()
> 
> (Unless invoking through debugfs ofc)

I thought you set the max_level or whatever to OOPS. Doesn't that mean
it gets involved for non-panics as well?

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/v3d: Fix calling drm_sched_resubmit_jobs for same sched.

[Eric Anholt]

Andrey Grodzovsky  writes:

> Also stop calling drm_sched_increase_karma multiple times.

Each v3d->queue[q].sched was initialized with a separate
drm_sched_init().  I wouldn't have thought they were all the "same
sched".


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm: Add helpers for locking an array of BO reservations.

[Eric Anholt]

Rob Herring  writes:

> On Fri, Mar 8, 2019 at 10:17 AM Eric Anholt  wrote:
>>
>> Now that we have the reservation object in the GEM object, it's easy
>> to provide a helper for this common case.  Noticed while reviewing
>> panfrost and lima drivers.  This particular version came out of v3d,
>> which in turn was a copy from vc4.
>>
>> Signed-off-by: Eric Anholt 
>> ---
>>  drivers/gpu/drm/drm_gem.c | 76 +++
>>  include/drm/drm_gem.h |  4 +++
>>  2 files changed, 80 insertions(+)
>
> Sweet! I was about to go write this same patch. You are changing the
> license from GPL to MIT copying the v3d version, but I guess you have
> rights to do that.
>
> FWIW,
>
> Acked-by: Rob Herring 

Was this just for this one patch, or the series?  I don't think I can
merge without a consumer.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output

[Noralf Trønnes]

Den 12.03.2019 18.25, skrev Ville Syrjälä:
> On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 12.03.2019 17.17, skrev Ville Syrjälä:
>>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
 On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> This adds support for outputting kernel messages on panic().
> A kernel message dumper is used to dump the log. The dumper iterates
> over each DRM device and it's crtc's to find suitable framebuffers.
>
> All the other dumpers are run before this one except mtdoops.
> Only atomic drivers are supported.
>
> Signed-off-by: Noralf Trønnes 
> ---
>  [...]
>
> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
> index f0b34c977ec5..f3274798ecfe 100644
> --- a/include/drm/drm_framebuffer.h
> +++ b/include/drm/drm_framebuffer.h
> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
>struct drm_file *file_priv, unsigned flags,
>unsigned color, struct drm_clip_rect *clips,
>unsigned num_clips);
> +
> + /**
> +  * @panic_vmap:
> +  *
> +  * Optional callback for panic handling.
> +  *
> +  * For vmapping the selected framebuffer in a panic context. Must
> +  * be super careful about locking (only trylocking allowed).
> +  *
> +  * RETURNS:
> +  *
> +  * NULL if it didn't work out, otherwise an opaque cookie which is
> +  * passed to @panic_draw_xy. It can be anything: vmap area, structure
> +  * with more details, just a few flags, ...
> +  */
> + void *(*panic_vmap)(struct drm_framebuffer *fb);

 FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
 drivers:

 Framebuffers are normally tiled, writing to them with the CPU results in
 garbled output.

>>
>> In which case the driver needs to support the ->panic_draw_xy callback,
>> or maybe it's possible to make a generic helper for tiled buffers.
>>
 With a discrete GPU having a large amount of VRAM, the framebuffer may
 not be directly CPU accessible at all.

>>
>> I would have been nice to know how Windows works around this.
>>

 There would need to be a mechanism for switching scanout to a linear,
 CPU accessible framebuffer.
>>>
>>> I suppose panic_vmap() could just provide a linear temp buffer
>>> to the panic handler, and panic_unmap() could copy the contents
>>> over to the real fb.
>>>
>>> That said, this approach of scribbling over the primary plane's
>>> framebuffer has some clear limitations:
>>> * something may overwrite the oops message before the user
>>>   can even read it
>>
>> When the dumper drm_panic_kmsg_dump() runs, the other CPU's should have
>> been stopped. See panic().
> 
> GPUs etc. may still be executing away.
> 

Would it be safe to stop it in a panic situation? It would ofc be bad to
crash the box even harder.

>>
>>> * there may be other planes obscuring part or all of the
>>>   primary plane
>>>
>>
>> Yeah, this is a problem, again I wonder how Windows deals with this.
> 
> Probably just disables all other planes. Not that it uses planes
> all that heavily.
> 
>>
>>> Also scribbling over the user's framebuffer seems rather rude
>>> to me, so I'm thinking this approach should be limited to kernel
>>> panics only.
>>>
>>
>> Yes this will only happen on kernel panics:
>>
>> panic() -> kmsg_dump() -> drm_panic_kmsg_dump()
>>
>> (Unless invoking through debugfs ofc)
> 
> I thought you set the max_level or whatever to OOPS. Doesn't that mean
> it gets involved for non-panics as well?
> 

I do that in the debugfs code, but I can't remember why I lower level, I
think can just change the level when invoking the dumper:
 drm_panic_file_panic_write(...)
-   kmsg_dump(KMSG_DUMP_OOPS);
+   kmsg_dump(KMSG_DUMP_PANIC);


This is the dumper config:

static struct kmsg_dumper drm_panic_kmsg_dumper = {
.dump = drm_panic_kmsg_dump,
.max_reason = KMSG_DUMP_PANIC,
};

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output

[Noralf Trønnes]

Den 12.03.2019 18.37, skrev Noralf Trønnes:
> 
> 
> Den 12.03.2019 18.25, skrev Ville Syrjälä:
>> On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
>>>
>>>
>>> Den 12.03.2019 17.17, skrev Ville Syrjälä:
 On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
>> This adds support for outputting kernel messages on panic().
>> A kernel message dumper is used to dump the log. The dumper iterates
>> over each DRM device and it's crtc's to find suitable framebuffers.
>>
>> All the other dumpers are run before this one except mtdoops.
>> Only atomic drivers are supported.
>>
>> Signed-off-by: Noralf Trønnes 
>> ---
>>  [...]
>>
>> diff --git a/include/drm/drm_framebuffer.h 
>> b/include/drm/drm_framebuffer.h
>> index f0b34c977ec5..f3274798ecfe 100644
>> --- a/include/drm/drm_framebuffer.h
>> +++ b/include/drm/drm_framebuffer.h
>> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
>>   struct drm_file *file_priv, unsigned flags,
>>   unsigned color, struct drm_clip_rect *clips,
>>   unsigned num_clips);
>> +
>> +/**
>> + * @panic_vmap:
>> + *
>> + * Optional callback for panic handling.
>> + *
>> + * For vmapping the selected framebuffer in a panic context. 
>> Must
>> + * be super careful about locking (only trylocking allowed).
>> + *
>> + * RETURNS:
>> + *
>> + * NULL if it didn't work out, otherwise an opaque cookie which 
>> is
>> + * passed to @panic_draw_xy. It can be anything: vmap area, 
>> structure
>> + * with more details, just a few flags, ...
>> + */
>> +void *(*panic_vmap)(struct drm_framebuffer *fb);
>
> FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
> drivers:
>
> Framebuffers are normally tiled, writing to them with the CPU results in
> garbled output.
>
>>>
>>> In which case the driver needs to support the ->panic_draw_xy callback,
>>> or maybe it's possible to make a generic helper for tiled buffers.
>>>
> With a discrete GPU having a large amount of VRAM, the framebuffer may
> not be directly CPU accessible at all.
>
>>>
>>> I would have been nice to know how Windows works around this.
>>>
>
> There would need to be a mechanism for switching scanout to a linear,
> CPU accessible framebuffer.

 I suppose panic_vmap() could just provide a linear temp buffer
 to the panic handler, and panic_unmap() could copy the contents
 over to the real fb.

 That said, this approach of scribbling over the primary plane's
 framebuffer has some clear limitations:
 * something may overwrite the oops message before the user
   can even read it
>>>
>>> When the dumper drm_panic_kmsg_dump() runs, the other CPU's should have
>>> been stopped. See panic().
>>
>> GPUs etc. may still be executing away.
>>
> 
> Would it be safe to stop it in a panic situation? It would ofc be bad to
> crash the box even harder.
> 
>>>
 * there may be other planes obscuring part or all of the
   primary plane

>>>
>>> Yeah, this is a problem, again I wonder how Windows deals with this.
>>
>> Probably just disables all other planes. Not that it uses planes
>> all that heavily.
>>
>>>
 Also scribbling over the user's framebuffer seems rather rude
 to me, so I'm thinking this approach should be limited to kernel
 panics only.

>>>
>>> Yes this will only happen on kernel panics:
>>>
>>> panic() -> kmsg_dump() -> drm_panic_kmsg_dump()
>>>
>>> (Unless invoking through debugfs ofc)
>>
>> I thought you set the max_level or whatever to OOPS. Doesn't that mean
>> it gets involved for non-panics as well?
>>
> 
> I do that in the debugfs code, but I can't remember why I lower level,

Now I remember, it is so I can catch the null pointer debugfs test, but
that's not necessary since this is designed for panics, so I should
remove that test.

Noralf.

> I
> think can just change the level when invoking the dumper:
>  drm_panic_file_panic_write(...)
> - kmsg_dump(KMSG_DUMP_OOPS);
> + kmsg_dump(KMSG_DUMP_PANIC);
> 
> 
> This is the dumper config:
> 
> static struct kmsg_dumper drm_panic_kmsg_dumper = {
>   .dump = drm_panic_kmsg_dump,
>   .max_reason = KMSG_DUMP_PANIC,
> };
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/v3d: Fix calling drm_sched_resubmit_jobs for same sched.

[Grodzovsky, Andrey]

They are not the same, but the guilty job belongs to only one {entity, 
scheduler} pair and so we mark as guilty only for that particular entity in the 
context of that scheduler only once.

Andrey


From: Eric Anholt 
Sent: 12 March 2019 13:33:16
To: Grodzovsky, Andrey; dri-devel@lists.freedesktop.org; 
amd-...@lists.freedesktop.org; to...@tomeuvizoso.net
Cc: Grodzovsky, Andrey
Subject: Re: [PATCH] drm/v3d: Fix calling drm_sched_resubmit_jobs for same 
sched.

Andrey Grodzovsky  writes:

> Also stop calling drm_sched_increase_karma multiple times.

Each v3d->queue[q].sched was initialized with a separate
drm_sched_init().  I wouldn't have thought they were all the "same
sched".
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output

[Ville Syrjälä]

On Tue, Mar 12, 2019 at 06:37:57PM +0100, Noralf Trønnes wrote:
> 
> 
> Den 12.03.2019 18.25, skrev Ville Syrjälä:
> > On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 12.03.2019 17.17, skrev Ville Syrjälä:
> >>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
>  On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> > This adds support for outputting kernel messages on panic().
> > A kernel message dumper is used to dump the log. The dumper iterates
> > over each DRM device and it's crtc's to find suitable framebuffers.
> >
> > All the other dumpers are run before this one except mtdoops.
> > Only atomic drivers are supported.
> >
> > Signed-off-by: Noralf Trønnes 
> > ---
> >  [...]
> >
> > diff --git a/include/drm/drm_framebuffer.h 
> > b/include/drm/drm_framebuffer.h
> > index f0b34c977ec5..f3274798ecfe 100644
> > --- a/include/drm/drm_framebuffer.h
> > +++ b/include/drm/drm_framebuffer.h
> > @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
> >  struct drm_file *file_priv, unsigned flags,
> >  unsigned color, struct drm_clip_rect *clips,
> >  unsigned num_clips);
> > +
> > +   /**
> > +* @panic_vmap:
> > +*
> > +* Optional callback for panic handling.
> > +*
> > +* For vmapping the selected framebuffer in a panic context. 
> > Must
> > +* be super careful about locking (only trylocking allowed).
> > +*
> > +* RETURNS:
> > +*
> > +* NULL if it didn't work out, otherwise an opaque cookie which 
> > is
> > +* passed to @panic_draw_xy. It can be anything: vmap area, 
> > structure
> > +* with more details, just a few flags, ...
> > +*/
> > +   void *(*panic_vmap)(struct drm_framebuffer *fb);
> 
>  FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
>  drivers:
> 
>  Framebuffers are normally tiled, writing to them with the CPU results in
>  garbled output.
> 
> >>
> >> In which case the driver needs to support the ->panic_draw_xy callback,
> >> or maybe it's possible to make a generic helper for tiled buffers.
> >>
>  With a discrete GPU having a large amount of VRAM, the framebuffer may
>  not be directly CPU accessible at all.
> 
> >>
> >> I would have been nice to know how Windows works around this.
> >>
> 
>  There would need to be a mechanism for switching scanout to a linear,
>  CPU accessible framebuffer.
> >>>
> >>> I suppose panic_vmap() could just provide a linear temp buffer
> >>> to the panic handler, and panic_unmap() could copy the contents
> >>> over to the real fb.
> >>>
> >>> That said, this approach of scribbling over the primary plane's
> >>> framebuffer has some clear limitations:
> >>> * something may overwrite the oops message before the user
> >>>   can even read it
> >>
> >> When the dumper drm_panic_kmsg_dump() runs, the other CPU's should have
> >> been stopped. See panic().
> > 
> > GPUs etc. may still be executing away.
> > 
> 
> Would it be safe to stop it in a panic situation? It would ofc be bad to
> crash the box even harder.

Some drivers/devices may have working (and hopefully even reliable)
gpu reset, some may not.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 1/4] drm/msm/gpu: Move zap shader loading to adreno

[Jordan Crouse]

a5xx and a6xx both share (mostly) the same code to load the zap shader and
bring the GPU out of secure mode. Move the formerly 5xx specific code to
adreno to make it available for a6xx too.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 109 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 113 
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |   6 ++
 3 files changed, 120 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d5f5e56..e5fcefa 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -15,9 +15,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -30,94 +27,6 @@ static void a5xx_dump(struct msm_gpu *gpu);
 
 #define GPU_PAS_ID 13
 
-static int zap_shader_load_mdt(struct msm_gpu *gpu, const char *fwname)
-{
-   struct device *dev = &gpu->pdev->dev;
-   const struct firmware *fw;
-   struct device_node *np;
-   struct resource r;
-   phys_addr_t mem_phys;
-   ssize_t mem_size;
-   void *mem_region = NULL;
-   int ret;
-
-   if (!IS_ENABLED(CONFIG_ARCH_QCOM))
-   return -EINVAL;
-
-   np = of_get_child_by_name(dev->of_node, "zap-shader");
-   if (!np)
-   return -ENODEV;
-
-   np = of_parse_phandle(np, "memory-region", 0);
-   if (!np)
-   return -EINVAL;
-
-   ret = of_address_to_resource(np, 0, &r);
-   if (ret)
-   return ret;
-
-   mem_phys = r.start;
-   mem_size = resource_size(&r);
-
-   /* Request the MDT file for the firmware */
-   fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
-   if (IS_ERR(fw)) {
-   DRM_DEV_ERROR(dev, "Unable to load %s\n", fwname);
-   return PTR_ERR(fw);
-   }
-
-   /* Figure out how much memory we need */
-   mem_size = qcom_mdt_get_size(fw);
-   if (mem_size < 0) {
-   ret = mem_size;
-   goto out;
-   }
-
-   /* Allocate memory for the firmware image */
-   mem_region = memremap(mem_phys, mem_size,  MEMREMAP_WC);
-   if (!mem_region) {
-   ret = -ENOMEM;
-   goto out;
-   }
-
-   /*
-* Load the rest of the MDT
-*
-* Note that we could be dealing with two different paths, since
-* with upstream linux-firmware it would be in a qcom/ subdir..
-* adreno_request_fw() handles this, but qcom_mdt_load() does
-* not.  But since we've already gotten thru adreno_request_fw()
-* we know which of the two cases it is:
-*/
-   if (to_adreno_gpu(gpu)->fwloc == FW_LOCATION_LEGACY) {
-   ret = qcom_mdt_load(dev, fw, fwname, GPU_PAS_ID,
-   mem_region, mem_phys, mem_size, NULL);
-   } else {
-   char *newname;
-
-   newname = kasprintf(GFP_KERNEL, "qcom/%s", fwname);
-
-   ret = qcom_mdt_load(dev, fw, newname, GPU_PAS_ID,
-   mem_region, mem_phys, mem_size, NULL);
-   kfree(newname);
-   }
-   if (ret)
-   goto out;
-
-   /* Send the image to the secure world */
-   ret = qcom_scm_pas_auth_and_reset(GPU_PAS_ID);
-   if (ret)
-   DRM_DEV_ERROR(dev, "Unable to authorize the image\n");
-
-out:
-   if (mem_region)
-   memunmap(mem_region);
-
-   release_firmware(fw);
-
-   return ret;
-}
-
 static void a5xx_flush(struct msm_gpu *gpu, struct msm_ringbuffer *ring)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -563,8 +472,6 @@ static int a5xx_zap_shader_resume(struct msm_gpu *gpu)
 static int a5xx_zap_shader_init(struct msm_gpu *gpu)
 {
static bool loaded;
-   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
-   struct platform_device *pdev = gpu->pdev;
int ret;
 
/*
@@ -574,23 +481,9 @@ static int a5xx_zap_shader_init(struct msm_gpu *gpu)
if (loaded)
return a5xx_zap_shader_resume(gpu);
 
-   /* We need SCM to be able to load the firmware */
-   if (!qcom_scm_is_available()) {
-   DRM_DEV_ERROR(&pdev->dev, "SCM is not available\n");
-   return -EPROBE_DEFER;
-   }
-
-   /* Each GPU has a target specific zap shader firmware name to use */
-   if (!adreno_gpu->info->zapfw) {
-   DRM_DEV_ERROR(&pdev->dev,
-   "Zap shader firmware file not specified for this 
target\n");
-   return -ENODEV;
-   }
-
-   ret = zap_shader_load_mdt(gpu, adreno_gpu->info->zapfw);
+   ret = adreno_zap_shader_load(gpu, GPU_PAS_ID);
 
loaded = !ret;
-
return ret;
 }
 
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 2789847..a9eb58c

[PATCH v1 2/4] drm/msm/a6xx: Add zap shader load

[Jordan Crouse]

The a6xx GPU powers on in secure mode which restricts what memory it can
write to. To get out of secure mode the GPU driver can write to
REG_A6XX_RBBM_SECVID_TRUST_CNTL but on targets that are "secure" that
register region is blocked and writes will cause the system to go down.

For those targets we need to execute a special sequence that involves
loadinga special shader that clears the GPU registers and use a PM4
sequence to pull the GPU out of secure. Add support for loading the zap
shader and executing the secure sequence. For targets that do not support
SCM or the specific SCM sequence this should fail and we would fall back
to writing the register.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  | 38 +-
 drivers/gpu/drm/msm/adreno/adreno_device.c |  1 +
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index fefe773..5983e47 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,6 +10,8 @@
 
 #include 
 
+#define GPU_PAS_ID 13
+
 static inline bool _a6xx_check_idle(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -343,6 +345,20 @@ static int a6xx_ucode_init(struct msm_gpu *gpu)
return 0;
 }
 
+static int a6xx_zap_shader_init(struct msm_gpu *gpu)
+{
+   static bool loaded;
+   int ret;
+
+   if (loaded)
+   return 0;
+
+   ret = adreno_zap_shader_load(gpu, GPU_PAS_ID);
+
+   loaded = !ret;
+   return ret;
+}
+
 #define A6XX_INT_MASK (A6XX_RBBM_INT_0_MASK_CP_AHB_ERROR | \
  A6XX_RBBM_INT_0_MASK_RBBM_ATB_ASYNCFIFO_OVERFLOW | \
  A6XX_RBBM_INT_0_MASK_CP_HW_ERROR | \
@@ -491,7 +507,27 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
if (ret)
goto out;
 
-   gpu_write(gpu, REG_A6XX_RBBM_SECVID_TRUST_CNTL, 0x0);
+   /*
+* Try to load a zap shader into the secure world. If successful
+* we can use the CP to switch out of secure mode. If not then we
+* have no resource but to try to switch ourselves out manually. If we
+* guessed wrong then access to the RBBM_SECVID_TRUST_CNTL register will
+* be blocked and a permissions violation will soon follow.
+*/
+   ret = a6xx_zap_shader_init(gpu);
+   if (!ret) {
+   OUT_PKT7(gpu->rb[0], CP_SET_SECURE_MODE, 1);
+   OUT_RING(gpu->rb[0], 0x);
+
+   a6xx_flush(gpu, gpu->rb[0]);
+   if (!a6xx_idle(gpu, gpu->rb[0]))
+   return -EINVAL;
+   } else {
+   /* Print a warning so if we die, we know why */
+   dev_warn_once(gpu->dev->dev,
+   "Zap shader not enabled - using SECVID_TRUST_CNTL 
instead\n");
+   gpu_write(gpu, REG_A6XX_RBBM_SECVID_TRUST_CNTL, 0x0);
+   }
 
 out:
/*
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 714ed65..ead5f6a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -155,6 +155,7 @@ static const struct adreno_info gpulist[] = {
.gmem = SZ_1M,
.inactive_period = DRM_MSM_INACTIVE_PERIOD,
.init = a6xx_gpu_init,
+   .zapfw = "a630_zap.mdt",
},
 };
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 3/4] dt-bindings: drm/msm/gpu: Document a5xx / a6xx zap shader region

[Jordan Crouse]

Describe the zap-shader node that defines a reserved memory region
to store the zap shader.

Signed-off-by: Jordan Crouse 
---

 Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index aad1aef..1e6d870 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -25,6 +25,9 @@ Required properties:
 - qcom,gmu: For GMU attached devices a phandle to the GMU device that will
   control the power for the GPU. Applicable targets:
 - qcom,adreno-630.2
+- zap-shader: For a5xx and a6xx devices this node contains a memory-region that
+  points to reserved memory to store the zap shader that can be used to help
+  bring the GPU out of secure mode.
 
 Example 3xx/4xx/a5xx:
 
@@ -71,5 +74,9 @@ Example a6xx (with GMU):
operating-points-v2 = <&gpu_opp_table>;
 
qcom,gmu = <&gmu>;
+
+   zap-shader {
+   memory-region = <&zap_shader_region>;
+   };
};
 };
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 0/4] drm/msm/a6xx: Add support for zap shader

[Jordan Crouse]

This patch series adds support for loading the zap shader on a6xx and using it
to get the GPU out of secure mode.

The Adreno a5xx and a6xx GPUs boot in "secure" mode which restricts the memory
the GPU is allowed to use. To get the GPU out of secure mode we need to write
to a register. However some bootloaders block access to this register and
require that the GPU instead perform a sequence to pull the GPU out of secure
mode. This sequence requires a special "zap" shader that will execute in
secure mode, clear out all the internal GPU settings and then transition to
in-secure mode.

This series adds support for loading and using the zap shader on a6xx assuming
that the shader exists and that the bootloader supports the secure mode. If any
part of the sequence fails then fall back to writing the register. If we get it
wrong, then writing to the register will trigger a protection mode error and
the system will go down.

The actual zap shader works almost identically to the one on 5xx outside of
a minor workaround for system resume. The first patch moves the a5xx specific
support to the generic adreno driver. The second patch add support for the
zap shader and the final two patches add the DT bindings and DT settings for
setting up the reserved memory that the shader requires.


Jordan Crouse (4):
  drm/msm/gpu: Move zap shader loading to adreno
  drm/msm/a6xx: Add zap shader load
  dt-bindings: drm/msm/gpu: Document a5xx / a6xx zap shader region
  arm64: dts: sdm845: Add zap shader region for GPU

 .../devicetree/bindings/display/msm/gpu.txt|   7 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi   |  11 ++
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c  | 109 +---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  38 ++-
 drivers/gpu/drm/msm/adreno/adreno_device.c |   1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c| 113 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|   6 ++
 7 files changed, 176 insertions(+), 109 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 02/10] drm: Added a new format DRM_FORMAT_XVYU2101010

[Ayan Halder]

From: Ayan Kumar Halder 

This new format is supported by DP550 and DP650

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder 
Reviewed-by: Liviu Dudau 
Acked-by: Alyssa Rosenzweig 
---
 drivers/gpu/drm/drm_fourcc.c  | 1 +
 include/uapi/drm/drm_fourcc.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index a9df743..3684c49 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -229,6 +229,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VUY888,  .depth = 0,  
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y410,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
.is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
.is_yuv = true },
+   { .format = DRM_FORMAT_XVYU2101010, .depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y210,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y212,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y216,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index b992a38..dc99e7f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -153,6 +153,7 @@ extern "C" {
 
 #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* 
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
 #define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* 
[31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XVYU2101010 fourcc_code('X', 'V', '3', '0') /* [31:0] 
X:Cr:Y:Cb 2:10:10:10 little endian */
 #define DRM_FORMAT_VUY888  fourcc_code('V', 'U', '2', '4') /* [23:0] 
Cr:Cb:Y 8:8:8 little endian */
 #define DRM_FORMAT_Y410fourcc_code('Y', '4', '1', '0') /* 
[31:0] A:Cr:Y:Cb 2:10:10:10 little endian */
 #define DRM_FORMAT_VUY101010   fourcc_code('V', 'U', '3', '0') /* Y followed 
by U then V, 10:10:10. Non-linear modifier only */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali

[Ayan Halder]

From: Brian Starkey 

As we look to enable AFBC using DRM format modifiers, we run into
problems which we've historically handled via vendor-private details
(i.e. gralloc, on Android).

AFBC (as an encoding) is fully flexible, and for example YUV data can
be encoded into 1, 2 or 3 encoded "planes", much like the linear
equivalents. Component order is also meaningful, as AFBC doesn't
necessarily care about what each "channel" of the data it encodes
contains. Therefore ABGR and RGBA can be encoded in AFBC with
different representations. Similarly, 'X' components may be encoded
into AFBC streams in cases where a decoder expects to decode a 4th
component.

In addition, AFBC is a licensable IP, meaning that to support the
ecosystem we need to ensure that _all_ AFBC users are able to describe
the encodings that they need. This is much better achieved by
preserving meaning in the fourcc codes when they are combined with an
AFBC modifier.

In essence, we want to use the modifier to describe the parameters of
the AFBC encode/decode, and use the fourcc code to describe the data
being encoded/decoded.

To do anything different would be to introduce redundancy - we would
need to duplicate in the modifier information which is _already_
conveyed clearly and non-ambigiously by a fourcc code.

I hope that for RGB this is non-controversial.
(BGRA + MODIFIER_AFBC) is a different format from
(RGBA + MODIFIER_AFBC).

Possibly more controversial is that (XBGR + MODIFIER_AFBC)
is different from (BGR888 + MODIFIER_AFBC). I understand that in some
schemes it is not the case - but in AFBC it is so.

Where we run into problems is where there are not already fourcc codes
which represent the data which the AFBC encoder/decoder is processing.
To that end, we want to introduce new fourcc codes to describe the
data being encoded/decoded, in the places where none of the existing
fourcc codes are applicable.

Where we don't support an equivalent non-compressed layout, or where
no "obvious" linear layout exists, we are proposing adding fourcc
codes which have no associated linear layout - because any layout we
proposed would be completely arbitrary.

Some formats are following the naming conventions from [2].

The summary of the new formats is:
 DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V.
 DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then
V. No defined linear encoding.
 DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y)
   then V. 10-bit samples in 16-bit words.
 DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha.
 DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by
   interleaved U-then-V plane. 10-bit samples in
   16-bit words.
 DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then
  V. No defined linear encoding
 DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U
   then V. No defined linear encoding

Please also note that in the absence of AFBC, we would still need to
add Y410, Y210 and P210.

Full rationale follows:

YUV 444 8-bit, 1-plane
--
 The currently defined AYUV format encodes a 4th alpha component,
 which makes it unsuitable for representing a 3-component YUV 444
 AFBC stream.

 The proposed[1] XYUV format which is supported by Mali-DP in linear
 layout is also unsuitable, because the component order is the
 opposite of the AFBC version, and it encodes a 4th 'X' component.

 DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed,
 YUV 444 8-bit format, with the component order which our HW expects to
 encode/decode. It conforms to the same naming convention as the
 existing packed YUV 444 format.
 The naming here is meant to be consistent with DRM_FORMAT_AYUV and
 DRM_FORMAT_XYUV[1]

YUV 444 10-bit, 1-plane
---
 There is no currently-defined YUV 444 10-bit format in
 drm_fourcc.h, irrespective of number of planes.

 The proposed[1] XVYU2101010 format which is supported by Mali-DP in
 linear layout uses the wrong component order, and also encodes a 4th
 'X' component, which doesn't match the AFBC version of YUV 444
 10-bit which we support.

 DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of
 alpha.  This format is supported with linear layout by Mali GPUs. The
 naming follows[2].

 There is no "obvious" linear encoding for a 3-component 10:10:10
 packed format, and so DRM_FORMAT_VUY101010 defines a component
 order, but not a bit encoding. Again, the naming is meant to be
 consistent with DRM_FORMAT_AYUV.

YUV 422 8-bit, 1-plane
--
 The existing DRM_FORMAT_YUYV (and the other component orders) are
 single-planar YUV 422 8-bit formats. Following the convention of
 the component orders of the RGB formats, YUYV has the correct
 component order for our AFBC encoding (Y followed by U followed by
 V)

[PATCH v4 04/10] drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650

[Ayan Halder]

From: Ayan Kumar Halder 

We have added support for some AFBC only pixel formats like :-
DRM_FORMAT_YUV420_8BIT (single plane YUV 420 8 bit format)
DRM_FORMAT_VUY888 (single plane YUV 444 8 bit format)
DRM_FORMAT_VUY101010 (single plane YUV 444 10 bit format)
DRM_FORMAT_YUV420_10BIT (single plane YUV 420 10 bit format)

Generally, these formats are supported by our hardware using the same
hw-ids as the equivalent multi plane pixel formats.

Also we have added support for XYUV 444 8 and 10 bit formats

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar Halder 
Reviewed-by: Liviu Dudau 
Acked-by: Alyssa Rosenzweig 
---
 drivers/gpu/drm/arm/malidp_hw.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 64c2ca3..b4a0e11 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -49,6 +49,12 @@ static const struct malidp_format_id malidp500_de_formats[] 
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1, 13 },
{ DRM_FORMAT_NV12, DE_VIDEO1 | SE_MEMWRITE, 14 },
{ DRM_FORMAT_YUV420, DE_VIDEO1, 15 },
+   { DRM_FORMAT_XYUV, DE_VIDEO1, 16 },
+   /* These are supported with AFBC only */
+   { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1, 14 },
+   { DRM_FORMAT_VUY888, DE_VIDEO1, 16 },
+   { DRM_FORMAT_VUY101010, DE_VIDEO1, 17 },
+   { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1, 18 }
 };
 
 #define MALIDP_ID(__group, __format) \
@@ -74,11 +80,25 @@ static const struct malidp_format_id malidp500_de_formats[] 
= {
{ DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, 
MALIDP_ID(4, 1) }, \
{ DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4, 
2) }, \
{ DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4, 
3) }, \
+   /* This is only supported with linear modifier */   \
+   { DRM_FORMAT_XYUV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) },\
+   /* This is only supported with AFBC modifier */ \
+   { DRM_FORMAT_VUY888, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) }, \
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
+   /* This is only supported with linear modifier */ \
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6) 
},  \
+   /* This is only supported with AFBC modifier */ \
+   { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) }, \
{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
-   { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
+   /* This is only supported with linear modifier */ \
+   { DRM_FORMAT_XVYU2101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+   /* This is only supported with AFBC modifier */ \
+   { DRM_FORMAT_VUY101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+   { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}, \
+   /* This is only supported with AFBC modifier */ \
+   { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}, \
+   { DRM_FORMAT_P010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}
 
 static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 07/10] drm/arm/malidp:- Writeback framebuffer does not support any modifiers

[Ayan Halder]

From: Ayan Kumar Halder 

In malidp, the writeback pipeline does not support writing crtc output
to a framebuffer with modifiers ie the memory writeback content is
devoid of any compression or tiling, etc.
So we have added a commit check in memory writeback encoder helper function
to validate if the framebuffer has any modifier and if so, return EINVAL.

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder 
Acked-by: Liviu Dudau 
Acked-by: Alyssa Rosenzweig 
---
 drivers/gpu/drm/arm/malidp_mw.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 28cd351..2865f7a 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -141,6 +141,11 @@ malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
 
+   if (fb->modifier) {
+   DRM_DEBUG_KMS("Writeback framebuffer does not support 
modifiers\n");
+   return -EINVAL;
+   }
+
mw_state->format =
malidp_hw_get_format_id(&malidp->dev->hw->map, SE_MEMWRITE,
fb->format->format, !!fb->modifier);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 06/10] drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats

[Ayan Halder]

From: Ayan Kumar Halder 

The newly supported AFBC YUV formats have the following rotation memory
constraints (in DP550/DP650).
1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
horizontal lines in the AFBC output buffer.
2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal lines
in the AFBC output buffer.

Also some of the pixel formats are specified in bits per pixel (rather
than bytes per pixel), so the calculation needs to take note of this.

Besides there are some difference between DP550 and DP650 and these are
as follows:-
1. DRM_FORMAT_X0L2 (in uncompressed format) does not support rotation in
DP550. For DP650, it can rotate upto 16 horizontal lines in the AFBC
output buffer, whereas in DP550 (with AFBC), it can rotate upto 8
horizontal lines.
2. DRM_FORMAT_YUV420_10BIT :- It can rotate upto 8 horizontal lines in
dp550 and 16 horizontal lines in DP650.

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder 
Reviewed-by: Liviu Dudau 
Acked-by: Alyssa Rosenzweig 
---
 drivers/gpu/drm/arm/malidp_hw.c | 101 
 drivers/gpu/drm/arm/malidp_hw.h |   5 +-
 drivers/gpu/drm/arm/malidp_planes.c |   3 +-
 3 files changed, 98 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 0ac2762..8df12e9 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -380,14 +380,39 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
 }
 
-static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w, 
u16 h, u32 fmt)
+int malidp_format_get_bpp(u32 fmt)
+{
+   int bpp = drm_format_plane_cpp(fmt, 0) * 8;
+
+   if (bpp == 0) {
+   switch (fmt) {
+   case DRM_FORMAT_VUY101010:
+   bpp = 30;
+   case DRM_FORMAT_YUV420_10BIT:
+   bpp = 15;
+   break;
+   case DRM_FORMAT_YUV420_8BIT:
+   bpp = 12;
+   break;
+   default:
+   bpp = 0;
+   }
+   }
+
+   return bpp;
+}
+
+static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
 {
/*
 * Each layer needs enough rotation memory to fit 8 lines
 * worth of pixel data. Required size is then:
 *size = rotated_width * (bpp / 8) * 8;
 */
-   return w * drm_format_plane_cpp(fmt, 0) * 8;
+   int bpp = malidp_format_get_bpp(fmt);
+
+   return w * bpp;
 }
 
 static void malidp500_se_write_pp_coefftab(struct malidp_hw_device *hwdev,
@@ -665,9 +690,9 @@ static void malidp550_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
 }
 
-static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w, 
u16 h, u32 fmt)
+static int malidpx50_get_bytes_per_column(u32 fmt)
 {
-   u32 bytes_per_col;
+   u32 bytes_per_column;
 
switch (fmt) {
/* 8 lines at 4 bytes per pixel */
@@ -693,19 +718,77 @@ static int malidp550_rotmem_required(struct 
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_X0L0:
-   case DRM_FORMAT_X0L2:
-   bytes_per_col = 32;
+   bytes_per_column = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
case DRM_FORMAT_NV12:
case DRM_FORMAT_YUV420:
-   bytes_per_col = 24;
+   /* 8 lines at 3 bytes per pixel */
+   case DRM_FORMAT_VUY888:
+   /* 16 lines at 12 bits per pixel */
+   case DRM_FORMAT_YUV420_8BIT:
+   /* 8 lines at 3 bytes per pixel */
+   case DRM_FORMAT_P010:
+   bytes_per_column = 24;
+   break;
+   /* 8 lines at 30 bits per pixel */
+   case DRM_FORMAT_VUY101010:
+   /* 16 lines at 15 bits per pixel */
+   case DRM_FORMAT_YUV420_10BIT:
+   bytes_per_column = 30;
break;
default:
return -EINVAL;
}
 
-   return w * bytes_per_col;
+   return bytes_per_column;
+}
+
+static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
+{
+   int bytes_per_column = 0;
+
+   switch (fmt) {
+   /* 8 lines at 15 bits per pixel */
+   case DRM_FORMAT_YUV420_10BIT:
+   bytes_per_column = 15;
+   break;
+   /* Uncompressed YUV 420 10 bit single plane cannot be rotated */
+   case DRM_FORMAT_X0L2:
+   if (has_modifier)
+   byte

[PATCH v4 09/10] drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer.

[Ayan Halder]

From: Ayan Kumar Halder 

Considering the fact that some of the AFBC specific pixel formats are expressed
in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width * bpp)
is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
For example, DRM_FORMAT_VUY101010 is 30 bits per pixel. For a framebuffer of
width 32 pixels, the pitch will be 120 bytes which is not aligned to burst size
(ie 16 bytes) for DP650.

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder 
Acked-by: Liviu Dudau 
Acked-by: Alyssa Rosenzweig 
---
 drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 3dc8a6f..044bf7f 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -531,8 +531,8 @@ static int malidp_de_plane_check(struct drm_plane *plane,
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
 
-   if ((fb->pitches[i] * drm_format_info_block_height(fb->format, 
i))
-   & (alignment - 1)) {
+   if (((fb->pitches[i] * drm_format_info_block_height(fb->format, 
i))
+   & (alignment - 1)) && !(fb->modifier)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
  fb->pitches[i], i);
return -EINVAL;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 03/10] drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier

[Ayan Halder]

From: Ayan Kumar Halder 

Added the AFBC decoder registers for DP500 , DP550 and DP650.
These registers control the processing of AFBC buffers. It controls various
features like AFBC decoder enable, lossless transformation and block split
as well as setting of the left, right, top and bottom cropping of AFBC
buffers (in number of pixels).
All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
One needs to set the pixel values of the top, left, bottom and right
cropping for the AFBC framebuffer.
Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
In that case, the layer input size registers should be configured with
framebuffer's dimensions and not with drm_plane_state source width/height
values (which is used for non AFBC framebuffer to denote cropping).

Changes from v1:
 - Removed the "if (fb->modifier)" check from malidp_de_plane_update()
and added it in malidp_de_set_plane_afbc(). This will consolidate all the
AFBC specific register configurations in a single function ie
malidp_de_set_plane_afbc().

Changes from v2:
 - For AFBC framebuffer, layer input size register should be set to
framebuffer's width and height.

Changes from v3:
- Rebased on top of latest drm-misc-next
- Some cleanups/sanity changes based on Liviu's comments

Changes from v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar Halder 
Reviewed-by: Liviu Dudau 
Acked-by: Alyssa Rosenzweig 
---
 drivers/gpu/drm/arm/malidp_hw.c |  30 ++
 drivers/gpu/drm/arm/malidp_hw.h |   2 +
 drivers/gpu/drm/arm/malidp_planes.c | 107 
 drivers/gpu/drm/arm/malidp_regs.h   |  20 +++
 4 files changed, 136 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index b9bed11..64c2ca3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -94,11 +94,14 @@ static const struct malidp_layer malidp500_layers[] = {
 *  yuv2rgb matrix offset, mmu control register offset, 
rotation_features
 */
{ DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
-   MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
+   MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY,
+   MALIDP500_DE_LV_AD_CTRL },
{ DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
-   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+   MALIDP500_DE_LG1_AD_CTRL },
{ DE_GRAPHICS2, MALIDP500_DE_LG2_BASE, MALIDP500_DE_LG2_PTR_BASE,
-   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+   MALIDP500_DE_LG2_AD_CTRL },
 };
 
 static const struct malidp_layer malidp550_layers[] = {
@@ -106,13 +109,16 @@ static const struct malidp_layer malidp550_layers[] = {
 *  yuv2rgb matrix offset, mmu control register offset, 
rotation_features
 */
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
-   MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+   MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+   MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
-   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+   MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+   MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
-   MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+   MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+   MALIDP550_DE_LV2_AD_CTRL },
{ DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
-   MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE },
+   MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE, 0 },
 };
 
 static const struct malidp_layer malidp650_layers[] = {
@@ -122,16 +128,18 @@ static const struct malidp_layer malidp650_layers[] = {
 */
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
-   MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+   MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY,
+   MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
MALIDP_DE_LG_STRIDE, 0, MALIDP650_DE_LG_MMU_CTRL,
-   ROTATE_COMPRESSED },
+   ROTATE_COMPRESSED, MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
-   MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+   MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY,
+   MALIDP550_DE_LV2_AD_CTRL },
 

[PATCH v4 05/10] drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650

[Ayan Halder]

From: Ayan Kumar Halder 

We need to define a common list of format modifiers supported by each of
the Mali display processors.

The following are the constraints with AFBC:-

1. AFBC is not supported for the formats defined in
malidp_hw_format_is_linear_only()

2. Some of the formats are supported only with AFBC modifiers. Thus we have
introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies
the same.

3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.

4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.

5. CBR should not be set for non-subsampled formats.

6. SMART layer does not support framebuffer with AFBC modifiers.
Return -EINVAL for such a scenario.

7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.

8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT.
However in DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT.
This feature has been identified with
MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.

9. In DP550 and DP650, for YUYV, the hardware supports different
format-ids to be used with and without AFBC modifier. We have used the
feature 'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this
characteristic.

10. DP500 does not support split mode (ie AFBC_FORMAT_MOD_SPLIT). We have
used the feature 'MALIDP_DEVICE_AFBC_SUPPORT_SPLIT' to identify the DPs
which support SPLIT mode.

11. DP550 supports YUV420 with split mode. We have defined the feature
'AFBC_SUPPORT_SPLIT_WITH_YUV_420_10' to identify this characteristic.

Changes since v1:-
- Merged https://patchwork.freedesktop.org/patch/265215/ into this patch
- As Liviu pointed out in the last patch, we can pull the checks outside
of the 'while (*modifiers != DRM_FORMAT_MOD_INVALID)' loop
- Rebased

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder 
Reviewed-by: Liviu Dudau 
Acked-by: Alyssa Rosenzweig 
---
 drivers/gpu/drm/arm/malidp_drv.c|  32 ++---
 drivers/gpu/drm/arm/malidp_drv.h|   6 ++
 drivers/gpu/drm/arm/malidp_hw.c |  96 +--
 drivers/gpu/drm/arm/malidp_hw.h |  24 +--
 drivers/gpu/drm/arm/malidp_mw.c |   2 +-
 drivers/gpu/drm/arm/malidp_planes.c | 126 +++-
 6 files changed, 246 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index ab50ad0..c697664 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -264,37 +264,17 @@ static bool
 malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd)
 {
-   const struct drm_format_info *info;
-
-   if ((mode_cmd->modifier[0] >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) {
-   DRM_DEBUG_KMS("Unknown modifier (not Arm)\n");
+   if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
+   mode_cmd->modifier[0]) == false)
return false;
-   }
-
-   if (mode_cmd->modifier[0] &
-   ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_MOD_VALID_BITS)) {
-   DRM_DEBUG_KMS("Unsupported modifiers\n");
-   return false;
-   }
-
-   info = drm_get_format_info(dev, mode_cmd);
-   if (!info) {
-   DRM_DEBUG_KMS("Unable to get the format information\n");
-   return false;
-   }
-
-   if (info->num_planes != 1) {
-   DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
-   return false;
-   }
 
if (mode_cmd->offsets[0] != 0) {
DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
return false;
}
 
-   switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
-   case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+   switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+   case AFBC_SIZE_16X16:
if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
DRM_DEBUG_KMS("AFBC buffers must be aligned to 16 
pixels\n");
return false;
@@ -319,8 +299,8 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
 
-   switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
-   case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+   switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+   case AFBC_SIZE_16X16:
afbc_superblock_height = 16;
afbc_superblock_width = 16;
break;
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index b76c86f..019a682 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -90,6 +90,12 @@ struct malidp_crtc_state {
 int malidp_de_planes_init(struct drm_device *drm);
 int malidp_crtc_init(struc

[PATCH v4 08/10] drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size

[Ayan Halder]

From: Ayan Kumar Halder 

Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
the calculation of AFBC framebuffer size needs to use malidp_format_get_bpp().

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder 
Reviewed-by: Liviu Dudau 
Acked-by: Alyssa Rosenzweig 
---
 drivers/gpu/drm/arm/malidp_drv.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c697664..4106f5d 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -298,6 +298,7 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
struct drm_gem_object *objs = NULL;
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
+   int bpp = 0;
 
switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
case AFBC_SIZE_16X16:
@@ -314,15 +315,19 @@ malidp_verify_afbc_framebuffer_size(struct drm_device 
*dev,
n_superblocks = (mode_cmd->width / afbc_superblock_width) *
(mode_cmd->height / afbc_superblock_height);
 
-   afbc_superblock_size = info->cpp[0] * afbc_superblock_width *
-   afbc_superblock_height;
+   bpp = malidp_format_get_bpp(info->format);
+
+   afbc_superblock_size = (bpp * afbc_superblock_width * 
afbc_superblock_height)
+   / BITS_PER_BYTE;
 
afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE, 
AFBC_SUPERBLK_ALIGNMENT);
afbc_size += n_superblocks * ALIGN(afbc_superblock_size, 
AFBC_SUPERBLK_ALIGNMENT);
 
-   if (mode_cmd->width * info->cpp[0] != mode_cmd->pitches[0]) {
-   DRM_DEBUG_KMS("Invalid value of pitch (=%u) should be same as 
width (=%u) * cpp (=%u)\n",
- mode_cmd->pitches[0], mode_cmd->width, 
info->cpp[0]);
+   if ((mode_cmd->width * bpp) != (mode_cmd->pitches[0] * BITS_PER_BYTE)) {
+   DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE) (=%u) "
+ "should be same as width (=%u) * bpp (=%u)\n",
+ (mode_cmd->pitches[0] * BITS_PER_BYTE),
+ mode_cmd->width, bpp);
return false;
}
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 10/10] drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART

[Ayan Halder]

From: Ayan Kumar Halder 

The list of modifiers to be supported for each plane has been dynamically 
generated
from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.

Changes from v1:-
1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
to report unsupported modifiers.

Changes from v2:-
1. Removed malidp_format_mod_supported() from the current patch. This has been 
added
in "PATCH 7/12"
2. Dynamically generate the list of modifiers (to be supported for each plane) 
from
'malidp_format_modifiers' and features.

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder 
Reviewed-by: Liviu Dudau 
Acked-by: Alyssa Rosenzweig 
---
 drivers/gpu/drm/arm/malidp_drv.c|  1 +
 drivers/gpu/drm/arm/malidp_planes.c | 31 ---
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 4106f5d..21725c9 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -391,6 +391,7 @@ static int malidp_init(struct drm_device *drm)
drm->mode_config.max_height = hwdev->max_line_size;
drm->mode_config.funcs = &malidp_mode_config_funcs;
drm->mode_config.helper_private = &malidp_mode_config_helpers;
+   drm->mode_config.allow_fb_modifiers = true;
 
ret = malidp_crtc_init(drm);
if (ret)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 044bf7f..d42e0ea 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -939,7 +939,26 @@ int malidp_de_planes_init(struct drm_device *drm)
  BIT(DRM_MODE_BLEND_PREMULTI)   |
  BIT(DRM_MODE_BLEND_COVERAGE);
u32 *formats;
-   int ret, i, j, n;
+   int ret, i = 0, j = 0, n;
+   u64 supported_modifiers[MODIFIERS_COUNT_MAX];
+   const u64 *modifiers;
+
+   modifiers = malidp_format_modifiers;
+
+   if (!(map->features & MALIDP_DEVICE_AFBC_SUPPORT_SPLIT)) {
+   /*
+* Since our hardware does not support SPLIT, so build the list
+* of supported modifiers excluding SPLIT ones.
+*/
+   while (*modifiers != DRM_FORMAT_MOD_INVALID) {
+   if (!(*modifiers & AFBC_SPLIT))
+   supported_modifiers[j++] = *modifiers;
+
+   modifiers++;
+   }
+   supported_modifiers[j++] = DRM_FORMAT_MOD_INVALID;
+   modifiers = supported_modifiers;
+   }
 
formats = kcalloc(map->n_pixel_formats, sizeof(*formats), GFP_KERNEL);
if (!formats) {
@@ -964,9 +983,15 @@ int malidp_de_planes_init(struct drm_device *drm)
 
plane_type = (i == 0) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
+
+   /*
+* All the layers except smart layer supports AFBC modifiers.
+*/
ret = drm_universal_plane_init(drm, &plane->base, crtcs,
-  &malidp_de_plane_funcs, formats,
-  n, NULL, plane_type, NULL);
+   &malidp_de_plane_funcs, formats, n,
+   (id == DE_SMART) ? NULL : modifiers, plane_type,
+   NULL);
+
if (ret < 0)
goto cleanup;
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Add binding for Armada framebuffer

[Rob Herring]

On Mon,  4 Mar 2019 21:20:02 +0100, Lubomir Rintel wrote:
> This is the binding for memory that is set aside for allocation of Marvell
> Armada framebuffer objects.
> 
> Signed-off-by: Lubomir Rintel 
> 
> ---
> Changes since v1:
> - Moved from bindings/display/armada/
> - Removed the marvell,dove-framebuffer string
> - Added to the MAINTAINERS entry
> 
>  .../marvell,armada-framebuffer.txt| 22 +++
>  MAINTAINERS   |  1 +
>  2 files changed, 23 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/reserved-memory/marvell,armada-framebuffer.txt
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] dt-bindings: display: armada: Add more compatible strings

[Rob Herring]

On Mon, Mar 04, 2019 at 09:20:05PM +0100, Lubomir Rintel wrote:
> There's a generic compatible string and the driver will work on a MMP2 as
> well, using the same binding.
> 
> Signed-off-by: Lubomir Rintel 
> 
> ---
> Changes since v1:
> - Added marvell,armada-lcdc compatible string.
> 
>  .../devicetree/bindings/display/marvell,armada-lcdc.txt   | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt 
> b/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
> index 2606a8efc956..4ef66bc2845c 100644
> --- a/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
> +++ b/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt
> @@ -3,7 +3,9 @@ Marvell Armada LCD controller
>  
>  Required properties:
>  
> - - compatible: value should be "marvell,dove-lcd".
> + - compatible: value should be "marvell,armada-lcdc" along with
> +   "marvell,dove-lcd" or "marvell,mmp2-lcd", depending on the
> +   exact SoC model.

It is not exactly clear what the order is here. The preferred form is:

compatible: must be one of:
 a
 b
 c
followed by 'fallback'

So "marvell,armada-lcdc" is the fallback, but you can't start requiring 
the existing "marvell,dove-lcd" to have a fallback. At least you can't 
depend on that.

>   - reg: base address and size of the LCD controller
>   - interrupts: single interrupt number for the LCD controller
>  
> -- 
> 2.20.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel