Re: [PATCH V8 5/5] drm/mediatek: make implementation of recalc_rate() to match the definition

2019-04-07 Thread CK Hu
Hi, Wangyan: On Tue, 2019-04-02 at 17:36 +0800, wangyan wang wrote: > From: Wangyan Wang > > Recalculate the rate of this clock, by querying hardware to > make implementation of recalc_rate() to match the definition. > > Signed-off-by: Wangyan Wang > --- >

Re: [PATCH V8 4/5] drm/mediatek: no change parent rate in round_rate() for mt2701 hdmi phy

2019-04-07 Thread CK Hu
Hi, Wangyan: On Tue, 2019-04-02 at 17:36 +0800, wangyan wang wrote: > From: Wangyan Wang > > This is the third step to make MT2701 HDMI stable. > We should not change the rate of parent for hdmi phy when > doing round_rate for this clock. The parent clock of hdmi > phy must be the same as it.

Re: [PATCH V8 3/5] drm/mediatek: using new factor for tvdpll in MT2701

2019-04-07 Thread CK Hu
Hi, Wangyan: On Tue, 2019-04-02 at 17:36 +0800, wangyan wang wrote: > From: Wangyan Wang > > This is the second step to make MT2701 HDMI stable. > The factor depends on the divider of DPI in MT2701, therefore, > we should fix this factor to the right and new one. Reviewed-by: CK Hu > >

Re: [PATCH V8 1/5] drm/mediatek: remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy to not propagate rate change to parent

2019-04-07 Thread CK Hu
Hi, Wangyan: On Tue, 2019-04-02 at 17:36 +0800, wangyan wang wrote: > From: Wangyan Wang > > This is the first step to make MT2701 hdmi stable. > The parent rate of hdmi phy had set by DPI driver. > We should not set or change the parent rate of MT2701 hdmi phy, > as a result we should remove

Re: [PATCH -next] MAINTAINERS: mark lima mailing list as moderated

2019-04-07 Thread Qiang Yu
Looks good for me, patch is: Reviewed-by: Qiang Yu Should I apply this patch to drm-misc in this case? Or this patch will be submitted in other kernel tree and back merged to drm-misc? Regards, Qiang On Mon, Apr 8, 2019 at 3:12 AM Randy Dunlap wrote: > > From: Randy Dunlap > > Note that the

Re: [mmotm:master 227/248] lima_gem.c:undefined reference to `vmf_insert_mixed'

2019-04-07 Thread Qiang Yu
Thanks Randy, I can add these. Where should I send/submit the patch to in this case? Still drm-misc? Regards, Qiang On Mon, Apr 8, 2019 at 3:08 AM Randy Dunlap wrote: > > On 4/5/19 11:47 PM, kbuild test robot wrote: > > Hi Andrew, > > > > It's probably a bug fix that unveils the link errors.

Re: [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI

2019-04-07 Thread Hoegeun Kwon
On 4/2/19 2:48 AM, Eric Anholt wrote: > Hoegeun Kwon writes: > >> There is a problem when often dpms goes from off to on. pm idle is not >> in sync and the problem occurs. Modify pm_runtime_put from >> asynchronous to synchronous. > Why would we need the power domain to go to off before we try to

[gabbayo:habanalabs-next 24/32] drivers/misc/habanalabs/habanalabs_ioctl.c:143:10-17: WARNING opportunity for memdup_user

2019-04-07 Thread kbuild test robot
tree: git://people.freedesktop.org/~gabbayo/linux habanalabs-next head: 19b649b1933c3ed065426d612345115d15d90f23 commit: e4d7235a3c44a17cb0a70e8dde768b6345ba5dd4 [24/32] habanalabs: add new IOCTL for debug, tracing and profiling coccinelle warnings: (new ones prefixed by >>) >>

[Bug 110347] pp_od_clk_voltage mV cap ignored

2019-04-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110347 --- Comment #3 from bednarczyk.pa...@outlook.com --- Created attachment 143888 --> https://bugs.freedesktop.org/attachment.cgi?id=143888=edit dmesg -- You are receiving this mail because: You are the assignee for the

[Bug 110347] pp_od_clk_voltage mV cap ignored

2019-04-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110347 --- Comment #2 from bednarczyk.pa...@outlook.com --- Created attachment 143887 --> https://bugs.freedesktop.org/attachment.cgi?id=143887=edit Xorg log -- You are receiving this mail because: You are the assignee for the

[PATCH v2 12/12] drm/client: Hack: Add bootsplash example

2019-04-07 Thread Noralf Trønnes
An example to showcase the client API. TODO: A bootsplash client needs a way to tell drm_fb_helper to stay away, otherwise it will chime in on setup and hotplug. Most DRM drivers register fbdev before calling drm_dev_register() (the generic emulation is an exception). This have to be reversed for

[PATCH v2 11/12] drm/fb-helper: Move out modeset config code

2019-04-07 Thread Noralf Trønnes
No functional changes, just moving code as-is and fixing includes. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_client_modeset.c | 703 ++- drivers/gpu/drm/drm_fb_helper.c | 692 -- include/drm/drm_client.h | 4 +- 3

[PATCH v2 10/12] drm/fb-helper: Prepare to move out modeset config code

2019-04-07 Thread Noralf Trønnes
This prepares the modeset code so it can be moved out as-is in the next patch. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_helper.c | 63 +++-- include/drm/drm_fb_helper.h | 4 --- 2 files changed, 45 insertions(+), 22 deletions(-) diff --git

[PATCH v2 08/12] drm/fb-helper: Move out commit code

2019-04-07 Thread Noralf Trønnes
Move the modeset commit code to drm_client_modeset. No changes except exporting API. v2: Move to drm_client_modeset.c instead of drm_client.c Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_client_modeset.c | 287 +++ drivers/gpu/drm/drm_fb_helper.c | 282

[PATCH v2 06/12] drm/fb-helper: Remove drm_fb_helper_crtc

2019-04-07 Thread Noralf Trønnes
It now only contains the modeset so use that directly instead and attach a modeset array to drm_client_dev. drm_fb_helper will use this array. Code will later be moved to drm_client, so add code there in a new file drm_client_modeset.c with MIT license to match drm_fb_helper.c. The modeset

[PATCH v2 04/12] drm/fb-helper: No need to cache rotation and sw_rotations

2019-04-07 Thread Noralf Trønnes
Getting rotation info is cheap so we can do it on demand. This is done in preparation for the removal of struct drm_fb_helper_crtc. Cc: Hans de Goede Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_helper.c | 131

[PATCH v2 07/12] drm/fb-helper: Prepare to move out commit code

2019-04-07 Thread Noralf Trønnes
This makes the necessary changes so the commit code can be moved out to drm_client as-is in the next patch. It's split up to ease review. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_helper.c | 122 +--- 1 file changed, 81 insertions(+), 41 deletions(-)

[PATCH v2 09/12] drm/fb-helper: Remove drm_fb_helper_connector

2019-04-07 Thread Noralf Trønnes
All drivers add all their connectors so there's no need to keep around an array of available connectors. Rename functions which signature is changed since they will be moved to drm_client in a later patch. Signed-off-by: Noralf Trønnes --- checkpatch complains, but I'm unable to satisfy it:

[PATCH v2 05/12] drm/fb-helper: Remove drm_fb_helper_crtc->{x, y, desired_mode}

2019-04-07 Thread Noralf Trønnes
The values are already present in the modeset. This is done in preparation for the removal of struct drm_fb_helper_crtc. Signed-off-by: Noralf Trønnes Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_helper.c | 12 include/drm/drm_fb_helper.h | 2 -- 2 files changed, 4

[PATCH v2 00/12] drm/fb-helper: Move modesetting code to drm_client

2019-04-07 Thread Noralf Trønnes
This moves the modesetting code from drm_fb_helper to drm_client so it can be shared by all internal clients. The main change this time is to attach the modeset array to drm_client_dev and honour the drm_fb_helper MIT license. I've dropped the display abstraction. Noralf. Cc: Emmanuel Vadot

[PATCH v2 03/12] drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper

2019-04-07 Thread Noralf Trønnes
It is generic code and having it in the helper will let other drivers benefit from it. One change was necessary assuming this to be true: INTEL_INFO(dev_priv)->num_pipes == dev->mode_config.num_crtc Suggested-by: Daniel Vetter Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc:

[PATCH v2 02/12] drm/fb-helper: Avoid race with DRM userspace

2019-04-07 Thread Noralf Trønnes
drm_fb_helper_is_bound() is used to check if DRM userspace is in control. This is done by looking at the fb on the primary plane. By the time fb-helper gets around to committing, it's possible that the facts have changed. Avoid this race by holding the drm_device->master_mutex lock while

[PATCH v2 01/12] drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()

2019-04-07 Thread Noralf Trønnes
Prepare for moving drm_fb_helper modesetting code to drm_client. drm_client will be linked to drm.ko, so move __drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config() out of drm_kms_helper.ko. While at it, fix two checkpatch complaints: - WARNING: Block comments use a trailing */

[Bug 109887] vega56 undervolting/overclocking voltage issues

2019-04-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109887 --- Comment #5 from bednarczyk.pa...@outlook.com --- Did you manage to get this resolved. I have the same issue and in my case setting P6 = P7 Frequency, the memory clock gets stuck at P0 167 Mhz. I tried 5.1 RC-3 but no joy either. -- You are

[Bug 110347] pp_od_clk_voltage mV cap ignored

2019-04-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110347 --- Comment #1 from bednarczyk.pa...@outlook.com --- I am able to work around the voltage issue by setting P6 frequency = P7 Frequency. In this case the voltage sits at the pre-defined value of 950mV, but I run into another problem. Memory

[Bug 110347] pp_od_clk_voltage mV cap ignored

2019-04-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110347 Bug ID: 110347 Summary: pp_od_clk_voltage mV cap ignored Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity:

Re: [PATCH v4] dt-bindings: gpu: add bindings for the ARM Mali Bifrost GPU

2019-04-07 Thread Neil Armstrong
Hi Rob, Le 01/04/2019 13:24, Neil Armstrong a écrit : > On 01/04/2019 12:00, Steven Price wrote: >> On 01/04/2019 09:09, Neil Armstrong wrote: >>> Add the bindings for the Bifrost family of ARM Mali GPUs. >>> >>> The Bifrost GPU architecture is similar to the Midgard family, >>> but with a