[Bug 111526] hhhhhhhhhh
https://bugs.freedesktop.org/show_bug.cgi?id=111526 Bug ID: 111526 Summary: hh Product: DRI Version: XOrg git Hardware: Alpha OS: Windows (All) Status: NEW Severity: critical Priority: high Component: DRM/amdkfd Assignee: dri-devel@lists.freedesktop.org Reporter: knsnileshkarande...@gmail.com -- 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 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #90 from Mauro Gaspari --- @Sam and @Jaap Buurman Can you please help and post system info regarding your crash? I hope that with more detailed reports, we can get better help. Example: OS Info can be taken from neofetch: System info: OS: openSUSE Tumbleweed Kernel: 5.2.10-1-default Resolution: 3440x1440 CPU: AMD Ryzen 7 2700X (16) @ 3.700GHz GPU: AMD ATI Radeon VII Memory: 6308MiB / 64387MiB Mesa info can be taken from this command: glxinfo | grep "OpenGL version" OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.1.5 Game being played: Eve Online Native or Wine or Wine+DXVK: Wine+DXVK Directx11 Crash type: Game crash? Full System freeze? System freeze but still can drop to tty? DMESG output after the crash: sudo dmesg | grep amdgpu systemd logs output after the crash (If your system did not freeze and you can get it before reboot): sudo journalctl -b | grep amdgpu systemd logs output after the crash (If your system froze and you get logs after reboot): sudo journalctl -b -1 | grep amdgpu If your distribution does not use persistent systemd logs you can change it according to your distribution. Example for openSUSE: https://www.suse.com/documentation/sles-12/book_sle_admin/data/journalctl_persistent.html -- 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 204725] black screen
https://bugzilla.kernel.org/show_bug.cgi?id=204725 --- Comment #8 from Dmitri Seletski (drj...@gmail.com) --- (In reply to Dmitri Seletski from comment #7) > I noticed, that when i do this, I get this: > lspci | grep -i VGA > 0d:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Device 731f (rev c1) > > My guess is that my device for some reason is not recognised. > > How would I go about it? scratch that. manipulation with GPU does happen. Just looks like bad string in the output that does not describe actual card. Also, if that makes any difference, I have display port to DVI adapter. for some reason my BENQ screen did not like direct HDMI cable. Cheapest HDMI cable in I could find. With that said, i am writing those words from VESA Xorg, using said displayport to DVI adapter.(looks like passive device) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204725] black screen
https://bugzilla.kernel.org/show_bug.cgi?id=204725 --- Comment #7 from Dmitri Seletski (drj...@gmail.com) --- I noticed, that when i do this, I get this: lspci | grep -i VGA 0d:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 731f (rev c1) My guess is that my device for some reason is not recognised. How would I go about it? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v4 00/16] new cgroup controller for gpu/drm subsystem
Hello, I just glanced through the interface and don't have enough context to give any kind of detailed review yet. I'll try to read up and understand more and would greatly appreciate if you can give me some pointers to read up on the resources being controlled and how the actual use cases would look like. That said, I have some basic concerns. * TTM vs. GEM distinction seems to be internal implementation detail rather than anything relating to underlying physical resources. Provided that's the case, I'm afraid these internal constructs being used as primary resource control objects likely isn't the right approach. Whether a given driver uses one or the other internal abstraction layer shouldn't determine how resources are represented at the userland interface layer. * While breaking up and applying control to different types of internal objects may seem attractive to folks who work day in and day out with the subsystem, they aren't all that useful to users and the siloed controls are likely to make the whole mechanism a lot less useful. We had the same problem with cgroup1 memcg - putting control of different uses of memory under separate knobs. It made the whole thing pretty useless. e.g. if you constrain all knobs tight enough to control the overall usage, overall utilization suffers, but if you don't, you really don't have control over actual usage. For memcg, what has to be allocated and controlled is physical memory, no matter how they're used. It's not like you can go buy more "socket" memory. At least from the looks of it, I'm afraid gpu controller is repeating the same mistakes. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #89 from Jaap Buurman --- Freezes are getting way more frequent for me as well :( -- 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 05/26] drm/dp_mst: Add sideband down request tracing + selftests
Two things below
On Tue, 2019-08-27 at 19:15 +0200, Daniel Vetter wrote:
> On Tue, Aug 27, 2019 at 12:49:17PM -0400, Lyude Paul wrote:
> > On Tue, 2019-08-13 at 16:50 +0200, Daniel Vetter wrote:
> > > On Wed, Jul 17, 2019 at 09:42:28PM -0400, Lyude Paul wrote:
> > > > Unfortunately the DP MST helpers do not have much in the way of
> > > > debugging utilities. So, let's add some!
> > > >
> > > > This adds basic debugging output for down sideband requests that we
> > > > send
> > > > from the driver, so that we can actually discern what's happening when
> > > > sideband requests timeout. Note that with this commit, we'll be
> > > > dumping
> > > > out sideband requests under both of the following conditions:
> > > >
> > > > - When the user has enabled DRM_UT_DP output, of course.
> > > > - When the user has enabled DRM_UT_KMS or DRM_UT_DP, and a sideband
> > > > request has failed in some way. This will allow for developers to
> > > > get
> > > > a basic idea of what's actually happening with failed modesets on
> > > > MST,
> > > > without needing to have DRM_UT_DP explicitly enabled.
> > > >
> > > > Since there wasn't really a good way of testing that any of this
> > > > worked,
> > > > I ended up writing simple selftests that lightly test sideband message
> > > > encoding and decoding as well. Enjoy!
> > > >
> > > > Cc: Juston Li
> > > > Cc: Imre Deak
> > > > Cc: Ville Syrjälä
> > > > Cc: Harry Wentland
> > > > Signed-off-by: Lyude Paul
> > > > ---
> > > > drivers/gpu/drm/drm_dp_mst_topology.c | 308
> > > > +-
> > > > .../gpu/drm/drm_dp_mst_topology_internal.h| 24 ++
> > > > .../gpu/drm/selftests/drm_modeset_selftests.h | 1 +
> > > > .../drm/selftests/test-drm_dp_mst_helper.c| 212
> > > > .../drm/selftests/test-drm_modeset_common.h | 1 +
> > > > include/drm/drm_dp_mst_helper.h | 2 +-
> > > > 6 files changed, 543 insertions(+), 5 deletions(-)
> > > > create mode 100644 drivers/gpu/drm/drm_dp_mst_topology_internal.h
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index 9e382117896d..defc5e09fb9a 100644
> > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > @@ -36,6 +36,8 @@
> > > > #include
> > > > #include
> > > >
> > > > +#include "drm_dp_mst_topology_internal.h"
> > > > +
> > > > /**
> > > > * DOC: dp mst helper
> > > > *
> > > > @@ -68,6 +70,8 @@ static int drm_dp_mst_register_i2c_bus(struct
> > > > drm_dp_aux
> > > > *aux);
> > > > static void drm_dp_mst_unregister_i2c_bus(struct drm_dp_aux *aux);
> > > > static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr);
> > > >
> > > > +#define DBG_PREFIX "[dp_mst]"
> > > > +
> > > > #define DP_STR(x) [DP_ ## x] = #x
> > > >
> > > > static const char *drm_dp_mst_req_type_str(u8 req_type)
> > > > @@ -124,6 +128,43 @@ static const char *drm_dp_mst_nak_reason_str(u8
> > > > nak_reason)
> > > > }
> > > >
> > > > #undef DP_STR
> > > > +#define DP_STR(x) [DRM_DP_SIDEBAND_TX_ ## x] = #x
> > > > +
> > > > +static const char *drm_dp_mst_sideband_tx_state_str(int state)
> > > > +{
> > > > + static const char * const sideband_reason_str[] = {
> > > > + DP_STR(QUEUED),
> > > > + DP_STR(START_SEND),
> > > > + DP_STR(SENT),
> > > > + DP_STR(RX),
> > > > + DP_STR(TIMEOUT),
> > > > + };
> > > > +
> > > > + if (state >= ARRAY_SIZE(sideband_reason_str) ||
> > > > + !sideband_reason_str[state])
> > > > + return "unknown";
> > > > +
> > > > + return sideband_reason_str[state];
> > > > +}
> > > > +
> > > > +static int
> > > > +drm_dp_mst_rad_to_str(const u8 rad[8], u8 lct, char *out, size_t len)
> > > > +{
> > > > + int i;
> > > > + u8 unpacked_rad[16];
> > > > +
> > > > + for (i = 0; i < lct; i++) {
> > > > + if (i % 2)
> > > > + unpacked_rad[i] = rad[i / 2] >> 4;
> > > > + else
> > > > + unpacked_rad[i] = rad[i / 2] & BIT_MASK(4);
> > > > + }
> > > > +
> > > > + /* TODO: Eventually add something to printk so we can format
> > > > the rad
> > > > +* like this: 1.2.3
> > > > +*/
> > >
> > > lct *=2;
> > >
> > > missing here? And yeah the todo would be sweet, but quite a bit more
> > > typing I guess.
> > >
> > > > + return snprintf(out, len, "%*phC", lct, unpacked_rad);
> > > > +}
> > > >
> > > > /* sideband msg handling */
> > > > static u8 drm_dp_msg_header_crc4(const uint8_t *data, size_t
> > > > num_nibbles)
> > > > @@ -256,8 +297,9 @@ static bool drm_dp_decode_sideband_msg_hdr(struct
> > > > drm_dp_sideband_msg_hdr *hdr,
> > > > return true;
> > > > }
> > > >
> > > > -static void drm_dp_encode_sideband_req(struct
> > > > drm_dp_sideband_msg_req_body *req,
> > > > -
Singaporean Mr. Teo En Ming's Refugee Seeking Attempts, In Search of a Substantially Better Life
Subject: Singaporean Mr. Teo En Ming's Refugee Seeking Attempts, In Search of a Substantially Better Life In reverse chronological order: [1] Petition to the Government of Taiwan for Refugee Status, 5th August 2019 Monday Photo #1: At the building of the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019 Photo #2: Queue ticket no. 515 at the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019 Photo #3: Submission of documents/petition to the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019 Photos #4 and #5: Acknowledgement of Receipt (no. 03142) for the submission of documents/petition from the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019, 10:00 AM References: (a) Petition to the Government of Taiwan for Refugee Status, 5th August 2019 Monday (Blogspot blog) Link: https://tdtemcerts.blogspot.sg/2019/08/petition-to-government-of-taiwan-for.html (b) Petition to the Government of Taiwan for Refugee Status, 5th August 2019 Monday (Wordpress blog) Link: https://tdtemcerts.wordpress.com/2019/08/23/petition-to-the-government-of-taiwan-for-refugee-status/ [2] Application for Refugee Status at the United Nations Refugee Agency, Bangkok, Thailand, 21st March 2017 Tuesday References: (a) [YOUTUBE] Vlog: The Road to Application for Refugee Status at the United Nations High Commissioner for Refugees, Bangkok Link: https://www.youtube.com/watch?v=utpuAa1eUNI YouTube video Published on March 22nd, 2017 Views as at 31st August 2019: 593 YouTube Channel: Turritopsis Dohrnii Teo En Ming Subscribers as at 31st August 2019: 2815 Link: https://www.youtube.com/channel/UC__F2hzlqNEEGx-IXxQi3hA -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #123 from ReddestDream --- A few interesting fixes that touch vega20_hwmgr.c have rolled in from drm-fixes: The first is likely the most interesting for our issues, as it touches min/maxes (tho only the soft ones it seems). The other two are related to SMU versions. https://github.com/torvalds/linux/commit/83e09d5bddbee749fc83063890244397896a1971 https://github.com/torvalds/linux/commit/21649c0b6b7899f4fa3099c46d3d027f60b107ec https://github.com/torvalds/linux/commit/23b7f6c41d4717b1638eca47e09d7e99fc7b9fd9 I haven't tested them out yet, but it does give me some hope that someone is still looking at Vega 20/Radeon VII . . . -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/mediatek: Bypass atomic helpers for cursor updates
Hi, Bibby:
On Fri, 2019-08-30 at 15:38 +0800, Bibby Hsieh wrote:
> Moving the driver to atomic helpers regressed cursor responsiveness,
> because cursor updates need their own atomic commits, which have to be
> serialized with other commits, that might include fence waits. To avoid
> this, in certain conditions, we can bypass the atomic helpers for legacy
> cursor update IOCTLs. Currently the conditions are:
> - no asynchronous mode setting commit pending,
> - no asynchronous commit that updates the cursor plane is pending.
> With the above two conditions met, we know that the manual cursor state
> update will not conflict with any scheduled update.
>
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
>
> Signed-off-by: Bibby Hsieh
> Signed-off-by: Daniel Kurtz
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 41 -
> drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 34 ++-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 +
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 73 +++-
> 5 files changed, 148 insertions(+), 5 deletions(-)
>
[snip]
> +
> +static int mtk_plane_update(struct drm_plane *plane,
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + int crtc_x, int crtc_y,
> + unsigned int crtc_w, unsigned int crtc_h,
> + uint32_t src_x, uint32_t src_y,
> + uint32_t src_w, uint32_t src_h,
> + struct drm_modeset_acquire_ctx *ctx)
> +{
> + struct mtk_drm_private *private = plane->dev->dev_private;
> + uint32_t crtc_mask = (1 << drm_crtc_index(crtc));
> +
> + if (crtc && plane == crtc->cursor &&
> + plane->state->crtc == crtc &&
> + !(private->commit.flush_for_cursor & crtc_mask))
> + return mtk_plane_cursor_update(plane, crtc, fb,
> + crtc_x, crtc_y, crtc_w, crtc_h,
> + src_x, src_y, src_w, src_h);
> +
> + return drm_atomic_helper_update_plane(plane, crtc, fb,
> + crtc_x, crtc_y, crtc_w, crtc_h,
> + src_x, src_y, src_w, src_h, ctx);
> +}
> +
> static const struct drm_plane_funcs mtk_plane_funcs = {
> - .update_plane = drm_atomic_helper_update_plane,
> + .update_plane = mtk_plane_update,
I think drm core has already process cursor async problem. In [1], you
could search 'legacy_cursor_update' and it need driver to implement
atomic_async_check() and atomic_async_update() callback function. You
could refer to [2] for the implementation.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_atomic_helper.c?h=v5.3-rc6
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_vop.c?h=v5.3-rc6#n955
Regards,
CK
> .disable_plane = drm_atomic_helper_disable_plane,
> .destroy = drm_plane_cleanup,
> .reset = mtk_plane_reset,
> @@ -90,7 +154,12 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
> if (!state->crtc)
> return 0;
>
> - crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> + if (state->state)
> + crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> + state->crtc);
> + else /* Special case for asynchronous cursor updates. */
> + crtc_state = state->crtc->state;
> +
> if (IS_ERR(crtc_state))
> return PTR_ERR(crtc_state);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111241] Shadertoy shader causing hang
https://bugs.freedesktop.org/show_bug.cgi?id=111241 --- Comment #12 from Dieter Nützel --- (In reply to Pierre-Eric Pelloux-Prayer from comment #11) > (In reply to Dieter Nützel from comment #8) > > BTW > > > > Pierre-Eric can you look into this > > > > Shadertoy shader corruption, too? > > https://www.shadertoy.com/view/Xt3cWS > > > > The "Buffer A" shader doesn't write fragColor when uv.y is < 0.1 or > 0.9. > > So the content is undefined and may be black on some platform or random. > > radeonsi is correct here, but we might want to replace undef values with 0x0 > to get a default value instead of random. Cool to have you around for bug hunting...;-) Any hints where I shoud change 'undef values with 0x0' for testing? And sorry that I 'hijacked' this thread - should I open a new ticket? -- 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 06/26] drm/dp_mst: Move PDT teardown for ports into destroy_connector_work
On Tue, 2019-08-13 at 16:52 +0200, Daniel Vetter wrote:
> On Wed, Jul 17, 2019 at 09:42:29PM -0400, Lyude Paul wrote:
> > This will allow us to add some locking for port PDTs, which can't be
> > done from drm_dp_destroy_port() since we don't know what locks the
> > caller might be holding. Also, this gets rid of a good bit of unneeded
> > code.
> >
> > Cc: Juston Li
> > Cc: Imre Deak
> > Cc: Ville Syrjälä
> > Cc: Harry Wentland
> > Signed-off-by: Lyude Paul
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 42 +++
> > 1 file changed, 17 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index defc5e09fb9a..0295e007c836 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1509,31 +1509,22 @@ static void drm_dp_destroy_port(struct kref *kref)
> > container_of(kref, struct drm_dp_mst_port, topology_kref);
> > struct drm_dp_mst_topology_mgr *mgr = port->mgr;
> >
> > - if (!port->input) {
> > - kfree(port->cached_edid);
> > -
> > - /*
> > -* The only time we don't have a connector
> > -* on an output port is if the connector init
> > -* fails.
> > -*/
> > - if (port->connector) {
> > - /* we can't destroy the connector here, as
> > -* we might be holding the mode_config.mutex
> > -* from an EDID retrieval */
> > -
> > - mutex_lock(>destroy_connector_lock);
> > - list_add(>next, >destroy_connector_list);
> > - mutex_unlock(>destroy_connector_lock);
> > - schedule_work(>destroy_connector_work);
> > - return;
> > - }
> > - /* no need to clean up vcpi
> > -* as if we have no connector we never setup a vcpi */
> > - drm_dp_port_teardown_pdt(port, port->pdt);
> > - port->pdt = DP_PEER_DEVICE_NONE;
> > + /* There's nothing that needs locking to destroy an input port yet */
> > + if (port->input) {
> > + drm_dp_mst_put_port_malloc(port);
> > + return;
> > }
> > - drm_dp_mst_put_port_malloc(port);
> > +
> > + kfree(port->cached_edid);
> > +
> > + /*
> > +* we can't destroy the connector here, as we might be holding the
> > +* mode_config.mutex from an EDID retrieval
> > +*/
> > + mutex_lock(>destroy_connector_lock);
> > + list_add(>next, >destroy_connector_list);
> > + mutex_unlock(>destroy_connector_lock);
> > + schedule_work(>destroy_connector_work);
>
> So if I'm not completely blind this just flattens the above code flow (by
> inverting the if (port->input)).
Now I'm really remembering why I refactored this. The control flow on the
previous version of this is pretty misleading. To summarize so it's a bit more
obvious:
if (port->input) {
drm_dp_mst_put_port_malloc(port);
return;
} else if (port->connector) {
add_connector_to_destroy_list();
return;
/* ^ now, this is where PDT teardown happens */
} else {
drm_dp_port_teardown_pdt(port, port->pdt);
}
/* free edid etc etc */
So, I suppose the title of this patch would be more accurate if it was
"drm/dp_mst: Remove PDT teardown in destroy_port() and refactor"
I'll go ahead and change that
>
> > }
> >
> > /**
> > @@ -3881,7 +3872,8 @@ drm_dp_finish_destroy_port(struct drm_dp_mst_port
> > *port)
> > {
> > INIT_LIST_HEAD(>next);
> >
> > - port->mgr->cbs->destroy_connector(port->mgr, port->connector);
> > + if (port->connector)
>
> And this here I can't connect with the commit message. I'm confused, did
> something go wrong with some rebase here, and this patch should have a
> different title/summary?
> -Daniel
No, this is correct. In the previous drm_dp_destroy_port() function we only
added a port to the delayed destroy work if it had a connector on it. Now that
we add ports unconditionally, we have to check port->connector before trying
to call port->mgr->cbs->destroy_connector() since port->connector is no longer
guaranteed to be != NULL.
>
> > + port->mgr->cbs->destroy_connector(port->mgr, port->connector);
> >
> > drm_dp_port_teardown_pdt(port, port->pdt);
> > port->pdt = DP_PEER_DEVICE_NONE;
> > --
> > 2.21.0
> >
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #13 from Johannes Hirte --- It seems DCC is broken on Raven Ridge. So how about disabling it here, until the problems are solved? -- 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 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #5 from Mathieu Belanger --- It probably really depend of what we do on our desktop. I just remember now how I did stop using FileZilla since I got that GPU as it was crashing almost all the time I was using it (Like I never not crashed while that thing was open and running). Still use it for work but I keep it to minimum (open, upload, close) instead of keeping it running. -- 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/mcde: Fix DSI transfers
Hi Linus,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.3-rc6 next-20190830]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Linus-Walleij/drm-mcde-Fix-DSI-transfers/20190831-051121
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/platform_device.h:13:0,
from drivers/gpu/drm/mcde/mcde_dsi.c:9:
drivers/gpu/drm/mcde/mcde_dsi.c: In function 'mcde_dsi_host_transfer':
>> drivers/gpu/drm/mcde/mcde_dsi.c:304:20: warning: format '%d' expects
>> argument of type 'int', but argument 3 has type 'size_t {aka const long
>> unsigned int}' [-Wformat=]
dev_err(d->dev, "read error, requested %d got %d\n",
^
include/linux/device.h:1416:22: note: in definition of macro 'dev_fmt'
#define dev_fmt(fmt) fmt
^~~
>> drivers/gpu/drm/mcde/mcde_dsi.c:304:4: note: in expansion of macro 'dev_err'
dev_err(d->dev, "read error, requested %d got %d\n",
^~~
vim +304 drivers/gpu/drm/mcde/mcde_dsi.c
167
168 #define MCDE_DSI_HOST_IS_READ(type) \
169 ((type == MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM) || \
170 (type == MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM) || \
171 (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
172 (type == MIPI_DSI_DCS_READ))
173
174 static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
175const struct mipi_dsi_msg *msg)
176 {
177 struct mcde_dsi *d = host_to_mcde_dsi(host);
178 const u32 loop_delay_us = 10; /* us */
179 const u8 *tx = msg->tx_buf;
180 u32 loop_counter;
181 size_t txlen = msg->tx_len;
182 size_t rxlen = msg->rx_len;
183 u32 val;
184 int ret;
185 int i;
186
187 if (txlen > 16) {
188 dev_err(d->dev,
189 "dunno how to write more than 16 bytes yet\n");
190 return -EIO;
191 }
192 if (rxlen > 4) {
193 dev_err(d->dev,
194 "dunno how to read more than 4 bytes yet\n");
195 return -EIO;
196 }
197
198 dev_dbg(d->dev,
199 "message to channel %d, write %zd bytes read %zd
bytes\n",
200 msg->channel, txlen, rxlen);
201
202 /* Command "nature" */
203 if (MCDE_DSI_HOST_IS_READ(msg->type))
204 /* MCTL_MAIN_DATA_CTL already set up */
205 val = DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_NAT_READ;
206 else
207 val = DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_NAT_WRITE;
208 /*
209 * More than 2 bytes will not fit in a single packet, so it's
210 * time to set the "long not short" bit. One byte is used by
211 * the MIPI DCS command leaving just one byte for the payload
212 * in a short package.
213 */
214 if (mipi_dsi_packet_format_is_long(msg->type))
215 val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LONGNOTSHORT;
216 val |= 0 << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_ID_SHIFT;
217 val |= txlen << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
218 val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LP_EN;
219 val |= msg->type << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SHIFT;
220 writel(val, d->regs + DSI_DIRECT_CMD_MAIN_SETTINGS);
221
222 /* MIPI DCS command is part of the data */
223 if (txlen > 0) {
224 val = 0;
225 for (i = 0; i < 4 && i < txlen; i++)
226 val |= tx[i] << (i & 3) * 8;
227 }
228 writel(val, d->regs + DSI_DIRECT_CMD_WRDAT0);
229 if (txlen > 4) {
230 val = 0;
231 for (i = 0; i < 4 && (i + 4) < txlen; i++)
232 val |= tx[i + 4] << (i & 3) * 8;
233 writel(val, d->regs + DSI_DIRECT_CMD_WRDAT1);
234 }
235 if (txlen > 8) {
236 val = 0;
237
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #4 from Matthias Müller --- Forgot to mention: running Manjaro 5.3rc6.d0826.ga55aa89-1, mesa-git 1:19.3.0_devel.114849.0142dcb990e-1 and llvm-libs-git 10.0.0_r325376.70e158e09e9-1 And if it matters: firmware from https://aur.archlinux.org/packages/linux-firmware-agd5f-radeon-navi10/ v2019.08.26.14.36-1 -- 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 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #3 from Matthias Müller --- I don't know if i'm encountering the same bug, but it is at least similar. I don't get hard freezes/lockups, but i get a strange "stutterting", as if the whole OS halted for a few seconds, then continued for a few seconds...and the halted times grew while the "usable seconds" got shorter quickly to the point of unusability... It doesn't happen regularly (seems like anything between 30min and 120min) and i haven't yet made out a direct cause, but in journalctl, it seems the same messages appear every time when it begins: kernel: amdgpu: [powerplay] Failed to send message 0xf, response 0xfffb, param 0xfd6000 kernel: amdgpu: [powerplay] Failed to send message 0xf, response 0xfffb, param 0xfd6000 kernel: amdgpu :0f:00.0: [mmhub] VMC page fault (src_id:0 ring:169 vmid:0 pasid:0) kernel: amdgpu :0f:00.0: at page 0x60fd6000 from 18 kernel: amdgpu :0f:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00041152 after that there are a lot of these: kernel: amdgpu: [powerplay] Failed to send message 0x40, response 0xffc2 param 0x2 kernel: amdgpu: [powerplay] Failed to send message 0xe, response 0xffc2, param 0x80 until shutdown/hardreset. Maybe some observation that might help to narrow it down: The first time it occured, i had to do a few reboots that showed this behaviour right after startup until it finally worked again - for about 45min. As it didn't work again after around 10 reboots, i tried uninstalling corectrl (that i used to have a custom fan-curve) - and it finally booted normal again! I then installed radeon-profile to have fan-controll (i don't want to have the fans stand still on desktop, as the card gets over 80° C hot before the fans kick in...). The issue still occurs with radeon-profile, but at least every reboot is running fine... Other thing i noticed is that after the first "freeze" with radeon-profile lm_sensors stopped reporting the fanspeed for the card, it always stays at zero. So maybe it is related to fan-control or the sysfs interface in general? -- 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
[pull] amdgpu drm-next-5.4
Hi Dave, Daniel, Mostly bug fixes. The big addition is display support for renoir which is new for 5.4. I realize it's a bit late to add it but the rest of the code for renoir is already in so it would be nice to get the display part in as well. If not, let me know, and I'll respin without it. Thanks! The following changes since commit b4d857ded1c50fb2bd1168d6f80ae81397ae468b: drm/amd/display: 3.2.48 (2019-08-23 11:46:12 -0500) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.4-2019-08-30 for you to fetch changes up to 9c9284f9cee9052da4cad575da8dc5f2bbb31065: drm/amdgpu: Move null pointer dereference check (2019-08-30 15:37:17 -0500) drm-next-5.4-2019-08-30: amdgpu: - Add DC support for Renoir - Add some GPUVM hw bug workarounds - add support for the smu11 i2c controller - GPU reset vram lost bug fixes - Navi1x powergating fixes - Navi12 power fixes - Renoir power fixes - Misc bug fixes and cleanups Aaron Liu (4): drm/amdgpu: fix GFXOFF on Picasso and Raven2 drm/amd/powerplay: SMU_MSG_OverridePcieParameters is unsupport for APU drm/amdgpu: update IH_CHICKEN in oss 4.0 IP header for VG/RV series drm/amdgpu: fix no interrupt issue for renoir emu (v2) Alex Deucher (1): drm/amdgpu/virtual_dce: drop error message in hw_init Andrey Grodzovsky (6): drm/amd/display: Fix error message drm/amdgpu: Add RAS EEPROM table. drm/amd: Import smuio_11_0 headers for EEPROM access on Vega20 drm/amd/powerplay: Add interface to lock SMU HW I2C. drm/amdgpu: Vega20 SMU I2C HW engine controller. drm/amdgpu: Handle job is NULL use case in amdgpu_device_gpu_recover Austin Kim (1): drm/amdgpu: Move null pointer dereference check Bhawanpreet Lakha (20): drm/amd/display: Add Renoir registers (v3) drm/amd/display: Add Renoir clock registers list drm/amd/display: Add Renoir hw_seq register list drm/amd/display: Add pp_smu functions for Renoir drm/amd/display: Add Renoir irq_services (v2) drm/amd/display: Add hubp block for Renoir (v2) drm/amd/display: Add Renoir hubbub registers list drm/amd/display: Add Renoir Hubbub (v2) drm/amd/display: Add Renoir clock manager drm/amd/display: Add Renoir resource (v2) drm/amd/display: Add Renoir GPIO drm/amd/display: Add Renoir DML drm/amd/display: Fix register names drm/amd/display: Handle Renoir in DC drm/amd/display: Handle Renoir in amdgpu_dm (v2) drm/amd/display: call update_bw_bounding_box drm/amd/display: add dal_asic_id for renoir drm/amd/display: add dcn21 core DC changes drm/amd/display: build dcn21 blocks drm/amd/display: add Renoir to kconfig Colin Ian King (1): drm/amdgpu: fix spelling mistake "jumpimng" -> "jumping" Dan Carpenter (1): drm/amd/powerplay: Fix an off by one in navi10_get_smu_msg_index() Evan Quan (2): drm/amd/powerplay: correct Vega20 dpm level related settings drm/amd/powerplay: correct the pp_feature output on Arcturus Gang Ba (1): Revert "drm/amdgpu: free up the first paging queue v2" Hawking Zhang (1): drm/amdgpu: correct in_suspend setting for navi series Jean Delvare (2): drm/amd/amdgpu: hide voltage and power sensors on SI and KV parts drm/amdgpu/si: fix ASIC tests Kai-Heng Feng (1): drm/amdgpu: Add APTX quirk for Dell Latitude 5495 Masahiro Yamada (1): drm/amd: remove meaningless descending into amd/amdkfd/ Monk Liu (1): drm/amdgpu: introduce vram lost for reset (v2) Petr Cvek (1): drm/amdgpu: Fix undefined dm_ip_block for navi12 Prike Liang (4): drm/amdgpu: Initialize and update SDMA power gating drm/amd/powerplay: regards the APU always enable the dpm feature mask drm/amd/powerplay: enable populate DPM clocks table for swSMU APU drm/amd/powerplay: add the interface for getting ultimate frequency v3 Roman Li (3): drm/amd/display: Correct order of RV family clk managers for Renoir drm/amd/display: Add DCN2.1 changes to DML drm/amdgpu: Enable DC on Renoir Tianci.Yin (2): drm/amdgpu: keep the stolen memory in visible vram region drm/amdgpu/psp: keep TMR in visible vram region for SRIOV Xiaojie Yuan (4): drm/amdgpu: add dummy read for some GCVM status registers drm/amdgpu: enable vcn powergating for navi12 drm/amdgpu: enable athub powergating for navi12 drm/amd/powerplay: enable jpeg powergating for navi1x YueHaibing (2): drm/amdgpu/display: fix build error without CONFIG_DRM_AMD_DC_DSC_SUPPORT drm/amd/display: remove unused function setFieldWithMask drivers/gpu/drm/Makefile | 1 - drivers/gpu/drm/amd/amdgpu/Makefile| 2 +-
[Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=107296 --- Comment #17 from BRULE Herman --- Same here with 3400G -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] intel: sync i915_pciids.h with kernel
Add the new CML PCI IDS.
Align with kernel commit:
bfc4c359b2822 ("drm/i915/cml: Add Missing PCI IDs")
This is in sync with kernel header as of:
0747590267e7 ("drm-tip: 2019y-08m-30d-18h-03m-18s UTC integration manifest")
Cc: José Roberto de Souza
Signed-off-by: Anusha Srivatsa
---
intel/i915_pciids.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
index a70c982d..b1f66b11 100644
--- a/intel/i915_pciids.h
+++ b/intel/i915_pciids.h
@@ -466,7 +466,10 @@
INTEL_VGA_DEVICE(0x9BC5, info), \
INTEL_VGA_DEVICE(0x9BC8, info), \
INTEL_VGA_DEVICE(0x9BC4, info), \
- INTEL_VGA_DEVICE(0x9BC2, info)
+ INTEL_VGA_DEVICE(0x9BC2, info), \
+ INTEL_VGA_DEVICE(0x9BC6, info), \
+ INTEL_VGA_DEVICE(0x9BE6, info), \
+ INTEL_VGA_DEVICE(0x9BF6, info)
#define INTEL_KBL_IDS(info) \
INTEL_KBL_GT1_IDS(info), \
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #88 from Sam --- I have recently started to get even more frequent freezes even on Vulkan now on kernel 5.2.10 The workaround of the power profile still works (for me) and is the only way to avoid them: # echo manual > /sys/class/drm/card0/device/power_dpm_force_performance_level # echo 7 > /sys/class/drm/card0/device/pp_dpm_sclk -- 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 111487] AMD vega - display off/on -> solid green display
https://bugs.freedesktop.org/show_bug.cgi?id=111487 --- Comment #5 from bzz --- Ok, sry, problem with off/on display is still there. But with HDMI - DVI-D cable i have solid black screen instead of solid green screen with HDMI-HDMI cable -- 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 111487] AMD vega - display off/on -> solid green display
https://bugs.freedesktop.org/show_bug.cgi?id=111487 --- Comment #4 from bzz --- weird story continues. I've switched cable HDMI - HDMI to HDMI - DVI-D (so right now i cannot have full supported resolution by Dell U3014, but flickering is gone and when i turn off and on display, i dont' have solid green screen. Is the HDMI or higher resolution problem? Anyway, i can still see warnings in dmesg: [ 2556.247779] WARNING: CPU: 3 PID: 177 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:932 dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu] [ 2556.247779] Modules linked in: uas usb_storage fuse vhost_net vhost tap tun ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables bpfilter scsi_transport_iscsi af_packet br_netfilter bridge stp llc iscsi_ibft iscsi_boot_sysfs msr nls_iso8859_1 nls_cp437 vfat fat edac_mce_amd kvm_amd ccp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic aesni_intel ledtrig_audio snd_hda_codec_hdmi aes_x86_64 crypto_simd snd_hda_intel snd_hda_codec cryptd glue_helper snd_hda_core snd_hwdep eeepc_wmi snd_pcm pcspkr r8169 asus_wmi snd_timer sparse_keymap realtek snd sp5100_tco rfkill wmi_bmof k10temp i2c_piix4 soundcore libphy joydev gpio_amdpt gpio_generic button acpi_cpufreq hid_logitech_hidpp btrfs libcrc32c xor hid_logitech_dj raid6_pq hid_generic usbhid amdgpu amd_iommu_v2 gpu_sched i2c_algo_bit ttm drm_kms_helper crc32c_intel syscopyarea sysfillrect sysimgblt xhci_pci fb_sys_fops xhci_hcd drm usbcore wmi video [ 2556.247794] pinctrl_amd sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs [ 2556.247797] CPU: 3 PID: 177 Comm: kworker/u64:8 Tainted: GW 5.3.0-rc6-1.g2831011-default #1 openSUSE Tumbleweed (unreleased) [ 2556.247797] Hardware name: System manufacturer System Product Name/PRIME B450M-A, BIOS 1804 07/29/2019 [ 2556.247801] Workqueue: events_unbound commit_work [drm_kms_helper] [ 2556.247848] RIP: 0010:dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu] [ 2556.247849] Code: 83 c8 ff e9 58 3d f8 ff 48 c7 c7 58 cb 98 c0 e8 b9 fa 02 db 0f 0b 83 c8 ff e9 42 3d f8 ff 48 c7 c7 58 cb 98 c0 e8 a3 fa 02 db <0f> 0b 80 bb 9f 01 00 00 00 75 05 e9 d6 63 f8 ff 48 8b 83 f8 02 00 [ 2556.247850] RSP: 0018:c1a0404779b8 EFLAGS: 00010286 [ 2556.247851] RAX: 0024 RBX: 9daa62a9 RCX: 0006 [ 2556.247851] RDX: 0007 RSI: 0002 RDI: 9daa6ead9a10 [ 2556.247852] RBP: 9da94e7a R08: 02532c3cd37f R09: 9daa6e80 [ 2556.247852] R10: 0005a06c R11: 00032088 R12: 9daa62a9 [ 2556.247855] R13: 9daa19eac000 R14: 9daa64bedf00 R15: 9da94e7a0f68 [ 2556.247855] FS: () GS:9daa6eac() knlGS: [ 2556.247856] CS: 0010 DS: ES: CR0: 80050033 [ 2556.247856] CR2: 000800626ce4 CR3: 0007e7536000 CR4: 003406e0 [ 2556.247857] Call Trace: [ 2556.247900] dcn10_apply_ctx_for_surface+0x587/0x6a0 [amdgpu] [ 2556.247942] commit_planes_for_stream+0x488/0x860 [amdgpu] [ 2556.247983] dc_commit_updates_for_stream+0x942/0xab0 [amdgpu] [ 2556.248030] amdgpu_dm_commit_planes.constprop.0+0x7d7/0x9a0 [amdgpu] [ 2556.248072] amdgpu_dm_atomic_commit_tail+0x94c/0xfb0 [amdgpu] [ 2556.248073] ? __wb_calc_thresh+0x2a/0x100 [ 2556.248074] ? wb_calc_thresh+0x41/0x50 [ 2556.248075] ? __switch_to_asm+0x40/0x70 [ 2556.248076] ? __switch_to_asm+0x34/0x70 [ 2556.248076] ? __switch_to_asm+0x40/0x70 [ 2556.248077] ? __switch_to_asm+0x34/0x70 [ 2556.248079] ? __switch_to_asm+0x40/0x70 [ 2556.248079] ? __switch_to_asm+0x34/0x70 [ 2556.248080] ? __switch_to_asm+0x40/0x70 [ 2556.248080] ? __switch_to_asm+0x34/0x70 [ 2556.248081] ? __switch_to_asm+0x40/0x70 [ 2556.248081] ? __switch_to_asm+0x34/0x70 [ 2556.248082] ? __switch_to_asm+0x40/0x70 [ 2556.248082] ? __switch_to_asm+0x34/0x70 [ 2556.248083] ? __switch_to_asm+0x40/0x70 [ 2556.248084] ? __switch_to_asm+0x34/0x70 [ 2556.248085] ? __switch_to_asm+0x40/0x70 [ 2556.248086] ? trace_hardirqs_off_thunk+0x1a/0x30 [ 2556.248087] ? wait_for_completion_timeout+0xf3/0x110 [ 2556.248088] ? finish_task_switch+0x7e/0x280 [ 2556.248092] ? commit_tail+0x3c/0x70 [drm_kms_helper] [ 2556.248096] commit_tail+0x3c/0x70 [drm_kms_helper] [ 2556.248099] process_one_work+0x1df/0x380 [ 2556.248100] worker_thread+0x4d/0x400 [ 2556.248101] kthread+0xf9/0x130 [ 2556.248102] ? process_one_work+0x380/0x380 [ 2556.248103] ? kthread_park+0x80/0x80 [ 2556.248103] ret_from_fork+0x27/0x50 [ 2556.248104] ---[ end trace d9e405aa05e74f7a ]--- -- 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 v3 01/14] dt-bindings: display: renesas,cmm: Add R-Car CMM documentation
Hi Laurent,
On Mon, Aug 26, 2019 at 01:15:50PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Mon, Aug 26, 2019 at 09:59:43AM +0200, Jacopo Mondi wrote:
> > On Mon, Aug 26, 2019 at 09:34:41AM +0200, Geert Uytterhoeven wrote:
> > > On Sun, Aug 25, 2019 at 3:50 PM Jacopo Mondi
> > > wrote:
> > > > Add device tree bindings documentation for the Renesas R-Car Display
> > > > Unit Color Management Module.
> > > >
> > > > CMM is the image enhancement module available on each R-Car DU video
> > > > channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded).
> > > >
> > > > Signed-off-by: Jacopo Mondi
> > >
> > > Thanks for your patch!
> > >
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/display/renesas,cmm.txt
> > > > @@ -0,0 +1,33 @@
> > > > +* Renesas R-Car Color Management Module (CMM)
> > > > +
> > > > +Renesas R-Car image enhancement module connected to R-Car DU video
> > > > channels.
> > > > +
> > > > +Required properties:
> > > > + - compatible: shall be one or more of the following:
> > > > + - "renesas,cmm-r8a7795": for R8A7795 (R-Car H3) compatible CMM.
> > > > + - "renesas,cmm-r8a7796": for R8A7796 (R-Car M3-W) compatible CMM.
> > > > + - "renesas,cmm-r8a77965": for R8A77965 (R-Car M3-N) compatible CMM.
> > > > + - "renesas,cmm-r8a77990": for R8A77990 (R-Car E3) compatible CMM.
> > > > + - "renesas,cmm-r8a77995": for R8A77995 (R-Car D3) compatible CMM.
> > >
> > > Please use "renesas,-cmm" instead of "renesas,cmm-".
> >
> > I actually copied it from the r-car gpio bindings, and I liked
> > cmm- better. If you prefer I can change it though.
> >
> > > > + - "renesas,rcar-gen3-cmm": for a generic R-Car Gen3 compatible CMM.
> > > > + - "renesas,rcar-gen2-cmm": for a generic R-Car Gen2 compatible CMM.
> > > > +
> > > > + When the generic compatible string is specified, the SoC-specific
> > > > + version corresponding to the platform should be listed first.
> > > > +
> > > > + - reg: the address base and length of the memory area where CMM
> > > > control
> > > > + registers are mapped to.
> > > > +
> > > > + - clocks: phandle and clock-specifier pair to the CMM functional clock
> > > > + supplier.
> > >
> > > Thinking about yaml validation:
> > >
> > > power-domains?
> > > resets?
> >
> > They should indeed be documented.
>
> How about converting this binding to yaml alreay ? It should be fairly
> simple.
I'm trying to, and I'm having my portion of fun time at it.
The definition of the schema itself seems good, but I wonder, is this
the first renesas schema we have? Because it seems to me the schema
validator is having an hard time to digest the examplea 'clocks' and
'power-domains' properties, which have 1 phandle and 2 specifiers and 1
phandle and 1 specifier respectively for Rensas SoCs.
In other words, if in the example I have:
examples:
- |
cmm0: cmm@fea4 {
compatible = "renesas,r8a7796-cmm";
reg = <0 0xfea4 0 0x1000>;
clocks = < 711> < 1 phandle + 1 specifier
resets = < 711>;
power-domains = <>; < 1 phandle
};
The schema validation is good.
While if I use an actual example
- |
cmm0: cmm@fea4 {
compatible = "renesas,r8a7796-cmm";
reg = <0 0xfea4 0 0x1000>;
clocks = < CPG_MOD 711> < 1 phandle + 2 specifier
resets = < 711>;
power-domains = < R8A7796_PD_ALWAYS_ON>; < 1 phandle
}; + 1 specfier
The schema validation fails...
Error:
Documentation/devicetree/bindings/display/renesas,cmm.example.dts:20.29-30
syntax error
FATAL ERROR: Unable to parse input tree
Are clocks properties with > 2 entries and power-domains properties with
> 1 entries supported?
Because from what I read here:
https://github.com/robherring/yaml-bindings/blob/master/schemas/clock/clock.yaml
"The length of a clock specifier is defined by the value of a #clock-cells
property in the clock provider node."
And that's expected, but is the examples actually validated against the
clock provider pointed by the phandle? Because in that case, if we had a
yaml schema for the cpg-mssr provider, it would indeed specify clock-cells=2.
Do we need a schema for cpg-mssr first, or am I doing something else
wrong?
Thanks
j
>
> > > > +Example:
> > > > +
> > > > +
> > > > + cmm0: cmm@fea4 {
> > > > + compatible = "renesas,cmm-r8a7796";
> > > > + reg = <0 0xfea4 0 0x1000>;
> > > > + power-domains = < R8A7796_PD_ALWAYS_ON>;
> > > > + clocks = < CPG_MOD 711>;
> > > > + resets = < 711>;
> > > > + };
>
> --
> Regards,
>
> Laurent Pinchart
signature.asc
Description: PGP signature
Re: [PATCH] drm/virtio: Use vmalloc for command buffer allocations.
Hi Gerd, On Fri, Aug 30, 2019 at 4:16 AM Gerd Hoffmann wrote: > > Hi, > > > > > - kfree(vbuf->data_buf); > > > > + kvfree(vbuf->data_buf); > > > > > > if (is_vmalloc_addr(vbuf->data_buf)) ... > > > > > > needed here I gues? > > > > > > > kvfree() handles vmalloc/kmalloc/kvmalloc internally by doing that check. > > Ok. > > > - videobuf_vmalloc_to_sg in drivers/media/v4l2-core/videobuf-dma-sg.c, > > assumes contiguous array of scatterlist and that the buffer being converted > > is page aligned > > Well, vmalloc memory _is_ page aligned. True, but this function gets called for all potential enqueuings (eg resource_create_3d, resource_attach_backing) and I was concerned that some other usage in the future might not have that guarantee. But if that's overly being paranoid, I'm willing to backtrack on that. > sg_alloc_table_from_pages() does alot of what you need, you just need a > small loop around vmalloc_to_page() create a struct page array > beforehand. That feels like an extra allocation when under memory pressure and more work, to not gain much -- there still needs to be a function that iterates through all the pages. But I don't feel super strongly about it and can change it if you think that it will be less maintenance overhead. > Completely different approach: use get_user_pages() and don't copy the > execbuffer at all. This one I'd rather not do unless we can show that the copy is actually a problem. As it stands I expect this to be a fallback instead of the regular case, and if it's not then the VMs need to revisit how long the control queue size is. Right now most execbuffers end up being copied into a single contiguous buffer which results in 3 descriptors of the virtio queue. If vmalloc ends up being used (which is only a fallback because vmemdup_user tries kmalloc first still), then there'll be 66 descriptors for a 256KB buffer. I think that's fine for exceptional cases, but not ideal if it was commonplace. Chia-I suggested that we could have a flag for the ioctl execbuffer indicating that the buffer is BO to solve that, but again I'd prefer to see that it's actually a problem. I'll also be moving the sg table construction out of the critical section and properly accounting for the required number of descriptors before entering it in response to his comments. Thanks, Dave
[Bug 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #12 from Johannes Hirte --- On top of 5.2.11 it doesn't work either. It get even worse. Without the two patches, I can shutdown the system. With both patches applied, the system hangs completely after resume. I have to force it off. -- 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: [RFC][PATCH] drm: kirin: Fix dsi probe/attach logic
On Thu, Aug 29, 2019 at 11:52 PM Andrzej Hajda wrote:
>
> On 29.08.2019 19:39, Rob Clark wrote:
> > On Wed, Aug 28, 2019 at 11:06 PM John Stultz wrote:
> >> Since commit 83f35bc3a852 ("drm/bridge: adv7511: Attach to DSI
> >> host at probe time") landed in -next the HiKey board would fail
> >> to boot, looping:
> > No, please revert 83f35bc3a852.. that is going in the *complete* wrong
> > direction. We actually should be moving panels to not require dsi
> > host until attach time, similar to how bridges work, not the other way
> > around.
>
>
> Devices of panels and bridges controlled via DSI will not appear at all
> if DSI host is not created.
>
> So this is the only direction!!!
>
I disagree, there is really no harm in the bridge probing if there is no dsi.
Furthermore, it seems that this change broke a few other drivers.
> >
> > The problem is that, when dealing with bootloader enabled display, we
> > need to be really careful not to touch the hardware until the display
> > driver knows the bridge/panel is present. If the bridge/panel probes
> > after the display driver, we could end up killing scanout
> > (efifb/simplefb).. if the bridge/panel is missing some dependency and
> > never probes, it is rather unpleasant to be stuck trying to debug what
> > went wrong with no display.
>
>
> It has nothing to do with touching hardware, you can always (I hope)
> postpone it till all components are present.
Unfortunately this is harder than it sounds, since we need to read hw
revision registers for display and dsi blocks to know which hw
revision we are dealing with.
(Also, we need to avoid
drm_fb_helper_remove_conflicting_framebuffers() until we know we are
ready to go.)
We could possibly put more information in dt. But the less we depend
on dt, the easier time we'll have adding support for ACPI boot on the
windows arm laptops.
> But it is just requirement of device/driver model in Linux Kernel.
yes and no.. the way the existing bridges work with a bridge->attach()
step seems fairly pragmatic to me.
>
> >
> > Sorry I didn't notice that adv7511 patch before it landed, but the
> > right thing to do now is to revert it.
>
>
> The 1st version of the patch was posted at the end of April and final
> version was queued 1st July, so it was quite long time for discussions
> and tests.
sorry I didn't notice the patch sooner, most of my bandwidth goes to mesa.
> Reverting it now seems quite late, especially if the patch does right
> thing and there is already proper fix for one encoder (kirin), moreover
> revert will break another platforms.
kirin isn't the only other user of adv75xx.. at least it is my
understanding that this broke db410c as well.
> Of course it seems you have different opinion what is the right thing in
> this case, so if you convince us that your approach is better one can
> revert the patch.
I guess my strongest / most immediate opinion is to not break other
existing adv75xx bridge users.
Beyond that, I found doing mipi_dsi_attach() in bridge->attach() was
quite convenient to get display handover from efifb work. And that
was (previously) the way most of the bridges worked.
But maybe there is another way.. perhaps somehow the bridges/panels
could be added as sub-components using the component framework, to
prevent the toplevel drm device from probing until they are ready?
We'd still have the problem that the dsi component wants to be able to
read hw revision before registering dsi host.. but I suppose if CCF
exported a way that we could query whether the interface clk was
already enabled, we could have the clk enable/disable cycle that would
break efifb.
BR,
-R
Re: [git pull] drm fixes for 5.3-rc7
The pull request you sent on Fri, 30 Aug 2019 13:51:31 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-08-30 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f69f199271ec5f765b056dfca703587d6d2b7aae Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[Bug 204725] black screen
https://bugzilla.kernel.org/show_bug.cgi?id=204725 --- Comment #6 from Dmitri Seletski (drj...@gmail.com) --- Thank you very much for your response. Both values are set. I also attached .config file to the bugzilla report at the time of reporting problem. (none)dimko's Desktop /usr/src/linux # grep CONFIG_DRM_AMD_DC_DCN2_0 /usr/src/linux/.config CONFIG_DRM_AMD_DC_DCN2_0=y (none)dimko's Desktop /usr/src/linux # grep CONFIG_DRM_AMD_DC_DSC_SUPPORT /usr/src/linux/.config CONFIG_DRM_AMD_DC_DSC_SUPPORT=y Any other ideas please? Kind Regards Dmitri On 29/08/2019 03:36, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=204725 > > Alex Deucher (alexdeuc...@gmail.com) changed: > > What|Removed |Added > > CC||alexdeuc...@gmail.com > > --- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) --- > Make sure your config contains: > CONFIG_DRM_AMD_DC_DCN2_0=y > CONFIG_DRM_AMD_DC_DSC_SUPPORT=y > -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: Use vmalloc for command buffer allocations.
On Fri, Aug 30, 2019 at 4:16 AM Gerd Hoffmann wrote: > > Hi, > > > > > - kfree(vbuf->data_buf); > > > > + kvfree(vbuf->data_buf); > > > > > > if (is_vmalloc_addr(vbuf->data_buf)) ... > > > > > > needed here I gues? > > > > > > > kvfree() handles vmalloc/kmalloc/kvmalloc internally by doing that check. > > Ok. > > > - videobuf_vmalloc_to_sg in drivers/media/v4l2-core/videobuf-dma-sg.c, > > assumes contiguous array of scatterlist and that the buffer being converted > > is page aligned > > Well, vmalloc memory _is_ page aligned. > > sg_alloc_table_from_pages() does alot of what you need, you just need a > small loop around vmalloc_to_page() create a struct page array > beforehand. > > Completely different approach: use get_user_pages() and don't copy the > execbuffer at all. It would be really nice if execbuffer does not copy. The user space owns the buffer and may overwrite the contents immediately after the ioctl. We also need a flag to indicate that the ownership of the buffer is transferred to the kernel. > > cheers, > Gerd > > ___ > 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/virtio: Use vmalloc for command buffer allocations.
On Thu, Aug 29, 2019 at 2:24 PM David Riley wrote:
>
> Userspace requested command buffer allocations could be too large
> to make as a contiguous allocation. Use vmalloc if necessary to
> satisfy those allocations.
>
> Signed-off-by: David Riley
> ---
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +-
> drivers/gpu/drm/virtio/virtgpu_vq.c| 74 --
> 2 files changed, 73 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index ac60be9b5c19..a8732a8af766 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -195,7 +195,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
> *dev, void *data,
> if (ret)
> goto out_free;
>
> - buf = memdup_user(u64_to_user_ptr(exbuf->command), exbuf->size);
> + buf = vmemdup_user(u64_to_user_ptr(exbuf->command), exbuf->size);
> if (IS_ERR(buf)) {
> ret = PTR_ERR(buf);
> goto out_unresv;
> @@ -230,7 +230,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
> *dev, void *data,
> return 0;
>
> out_memdup:
> - kfree(buf);
> + kvfree(buf);
> out_unresv:
> ttm_eu_backoff_reservation(, _list);
> out_free:
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 981ee16e3ee9..bcbc48b7284f 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -154,7 +154,7 @@ static void free_vbuf(struct virtio_gpu_device *vgdev,
> {
> if (vbuf->resp_size > MAX_INLINE_RESP_SIZE)
> kfree(vbuf->resp_buf);
> - kfree(vbuf->data_buf);
> + kvfree(vbuf->data_buf);
> kmem_cache_free(vgdev->vbufs, vbuf);
> }
>
> @@ -251,6 +251,59 @@ void virtio_gpu_dequeue_cursor_func(struct work_struct
> *work)
> wake_up(>cursorq.ack_queue);
> }
>
> +/* How many bytes left in this page. */
> +static unsigned int rest_of_page(void *data)
> +{
> + return PAGE_SIZE - offset_in_page(data);
> +}
> +
> +/* Create sg_table from a vmalloc'd buffer. */
> +static struct sg_table *vmalloc_to_sgt(char *data, uint32_t size)
> +{
> + int nents, ret, s, i;
> + struct sg_table *sgt;
> + struct scatterlist *sg;
> + struct page *pg;
> +
> + sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
> + if (!sgt)
> + return NULL;
> +
> + nents = DIV_ROUND_UP(size, PAGE_SIZE) + 1;
> + ret = sg_alloc_table(sgt, nents, GFP_KERNEL);
> + if (ret) {
> + kfree(sgt);
> + return NULL;
> + }
> +
> + for_each_sg(sgt->sgl, sg, nents, i) {
> + pg = vmalloc_to_page(data);
> + if (!pg) {
> + sg_free_table(sgt);
> + kfree(sgt);
> + return NULL;
> + }
> +
> + s = rest_of_page(data);
> + if (s > size)
> + s = size;
> +
> + sg_set_page(sg, pg, s, offset_in_page(data));
> +
> + size -= s;
> + data += s;
> +
> + if (size) {
> + sg_unmark_end(sg);
> + } else {
> + sg_mark_end(sg);
> + break;
> + }
> + }
> +
> + return sgt;
> +}
> +
> static int virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device
> *vgdev,
>struct virtio_gpu_vbuffer
> *vbuf)
> __releases(>ctrlq.qlock)
> @@ -260,6 +313,7 @@ static int virtio_gpu_queue_ctrl_buffer_locked(struct
> virtio_gpu_device *vgdev,
> struct scatterlist *sgs[3], vcmd, vout, vresp;
> int outcnt = 0, incnt = 0;
> int ret;
> + struct sg_table *sgt = NULL;
>
> if (!vgdev->vqs_ready)
> return -ENODEV;
> @@ -269,8 +323,17 @@ static int virtio_gpu_queue_ctrl_buffer_locked(struct
> virtio_gpu_device *vgdev,
> outcnt++;
>
> if (vbuf->data_size) {
> - sg_init_one(, vbuf->data_buf, vbuf->data_size);
> - sgs[outcnt + incnt] =
> + if (is_vmalloc_addr(vbuf->data_buf)) {
> + spin_unlock(>ctrlq.qlock);
> + sgt = vmalloc_to_sgt(vbuf->data_buf, vbuf->data_size);
> + spin_lock(>ctrlq.qlock);
> + if (!sgt)
> + return -ENOMEM;
> + sgs[outcnt + incnt] = sgt->sgl;
If the construction of sgs is no longer atomic, it should be moved out
of the critical section.
> + } else {
> + sg_init_one(, vbuf->data_buf, vbuf->data_size);
> + sgs[outcnt + incnt] =
> + }
> outcnt++;
> }
>
> @@ -294,6 +357,11 @@
RE: [PATCH 2/9] dma-buf: make to_dma_fence_array NULL safe
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
>Of Christian König
>Sent: Monday, August 26, 2019 10:57 AM
>To: dri-devel@lists.freedesktop.org; ch...@chris-wilson.co.uk;
>daniel.vet...@ffwll.ch; sumit.sem...@linaro.org; linux-
>me...@vger.kernel.org; linaro-mm-...@lists.linaro.org
>Subject: [PATCH 2/9] dma-buf: make to_dma_fence_array NULL safe
>
>A bit surprising that this wasn't already the case.
>
>Signed-off-by: Christian König
>---
> include/linux/dma-fence-array.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-
>array.h
>index 303dd712220f..f99cd7eb24e0 100644
>--- a/include/linux/dma-fence-array.h
>+++ b/include/linux/dma-fence-array.h
>@@ -68,7 +68,7 @@ static inline bool dma_fence_is_array(struct dma_fence
>*fence)
> static inline struct dma_fence_array *
> to_dma_fence_array(struct dma_fence *fence)
> {
>- if (fence->ops != _fence_array_ops)
>+ if (!fence || fence->ops != _fence_array_ops)
> return NULL;
>
> return container_of(fence, struct dma_fence_array, base);
It looks like dma_fence_is_array() has the same issue.
Is it worth fixing?
Mike
>--
>2.17.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110865] Rx480 consumes 20w more power in idle than under Windows
https://bugs.freedesktop.org/show_bug.cgi?id=110865 --- Comment #35 from Martin --- Thank you for clarification, do you think there is a solution for the problem on the linux side, since it works absolutely fine on windows. -- 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 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #11 from Johannes Hirte --- With those two patches on top of v5.3-rc6-129-g265381004994 resume from S3 suspend still hangs with a black screen. I've had to hard reset the system, so I can't say for sure, if this is the same bug. -- 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 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #10 from Nicholas Kazlauskas --- (In reply to Johannes Hirte from comment #9) > git bisect points me to > > commit df8368be1382b442384507a5147c89978cd60702 (refs/bisect/bad) > Author: Nicholas Kazlauskas > Date: Wed Feb 27 12:56:36 2019 -0500 > > drm/amdgpu: Bump amdgpu version for per-flip plane tiling updates > > To help xf86-video-amdgpu and mesa know DC supports updating the > tiling attributes for a framebuffer per-flip. > > Cc: Michel Dänzer > Signed-off-by: Nicholas Kazlauskas > Acked-by: Alex Deucher > Reviewed-by: Marek Olšák > Signed-off-by: Alex Deucher > > > Does this make any sense? Yes, this is the commit that enabled mesa and xf86-video-amdgpu to use DCC for scanout. I recently fixed a bug where these warnings could be generated in some use sequences (notably immediate flipping). Please try amd-staging-drm-next or apply the following series to your kernel: https://patchwork.freedesktop.org/series/64614/ -- 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 110979] [amd tahiti xt][amdgpu] ERROR: "dm_ip_block" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!, without DC enabled
https://bugs.freedesktop.org/show_bug.cgi?id=110979 --- Comment #3 from Alex Deucher --- Applied. Thanks! -- 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/amdgpu: Move null pointer dereference check
On Fri, Aug 30, 2019 at 8:43 AM Austin Kim wrote:
>
> Null pointer dereference check should have been checked,
> ahead of below routine.
> struct amdgpu_device *adev = hwmgr->adev;
>
> With this commit, it could avoid potential NULL dereference.
>
> Signed-off-by: Austin Kim
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> index 8189fe4..4728aa2 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> @@ -722,16 +722,17 @@ static int smu8_request_smu_load_fw(struct pp_hwmgr
> *hwmgr)
>
> static int smu8_start_smu(struct pp_hwmgr *hwmgr)
> {
> - struct amdgpu_device *adev = hwmgr->adev;
> + struct amdgpu_device *adev;
>
> uint32_t index = SMN_MP1_SRAM_START_ADDR +
> SMU8_FIRMWARE_HEADER_LOCATION +
> offsetof(struct SMU8_Firmware_Header, Version);
>
> -
> if (hwmgr == NULL || hwmgr->device == NULL)
> return -EINVAL;
>
> + adev = hwmgr->adev;
> +
> cgs_write_register(hwmgr->device, mmMP0PUB_IND_INDEX, index);
> hwmgr->smu_version = cgs_read_register(hwmgr->device,
> mmMP0PUB_IND_DATA);
> pr_info("smu version %02d.%02d.%02d\n",
> --
> 2.6.2
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #9 from Johannes Hirte --- git bisect points me to commit df8368be1382b442384507a5147c89978cd60702 (refs/bisect/bad) Author: Nicholas Kazlauskas Date: Wed Feb 27 12:56:36 2019 -0500 drm/amdgpu: Bump amdgpu version for per-flip plane tiling updates To help xf86-video-amdgpu and mesa know DC supports updating the tiling attributes for a framebuffer per-flip. Cc: Michel Dänzer Signed-off-by: Nicholas Kazlauskas Acked-by: Alex Deucher Reviewed-by: Marek Olšák Signed-off-by: Alex Deucher Does this make any sense? -- 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 110979] [amd tahiti xt][amdgpu] ERROR: "dm_ip_block" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!, without DC enabled
https://bugs.freedesktop.org/show_bug.cgi?id=110979 --- Comment #2 from Petr Cvek --- The patch above should fix it, tested the compilation for MIPS + Polaris 11. The actual functionality was not tested (yet). -- 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 110979] [amd tahiti xt][amdgpu] ERROR: "dm_ip_block" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!, without DC enabled
https://bugs.freedesktop.org/show_bug.cgi?id=110979 Petr Cvek changed: What|Removed |Added CC||petrcve...@gmail.com --- Comment #1 from Petr Cvek --- Created attachment 145218 --> https://bugs.freedesktop.org/attachment.cgi?id=145218=edit The patch adds if defined block around undefined symbol -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mcde: Fix DSI transfers
There were bugs in the DSI transfer (read and write) function
as it was only tested with displays ever needing a single byte
to be written. Fixed it up and tested so we can now write
messages of up to 16 bytes and read up to 4 bytes from the
display.
Tested with a Sony ACX424AKP display: this display now self-
identifies and can control backlight in command mode.
Cc: Stephan Gerhold
Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/mcde/mcde_dsi.c | 70 ++---
1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index 07f7090d08b3..ad76a36e7bc1 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -178,22 +178,26 @@ static ssize_t mcde_dsi_host_transfer(struct
mipi_dsi_host *host,
const u32 loop_delay_us = 10; /* us */
const u8 *tx = msg->tx_buf;
u32 loop_counter;
- size_t txlen;
+ size_t txlen = msg->tx_len;
+ size_t rxlen = msg->rx_len;
u32 val;
int ret;
int i;
- txlen = msg->tx_len;
- if (txlen > 12) {
+ if (txlen > 16) {
dev_err(d->dev,
- "dunno how to write more than 12 bytes yet\n");
+ "dunno how to write more than 16 bytes yet\n");
+ return -EIO;
+ }
+ if (rxlen > 4) {
+ dev_err(d->dev,
+ "dunno how to read more than 4 bytes yet\n");
return -EIO;
}
dev_dbg(d->dev,
- "message to channel %d, %zd bytes",
- msg->channel,
- txlen);
+ "message to channel %d, write %zd bytes read %zd bytes\n",
+ msg->channel, txlen, rxlen);
/* Command "nature" */
if (MCDE_DSI_HOST_IS_READ(msg->type))
@@ -210,9 +214,7 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host
*host,
if (mipi_dsi_packet_format_is_long(msg->type))
val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LONGNOTSHORT;
val |= 0 << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_ID_SHIFT;
- /* Add one to the length for the MIPI DCS command */
- val |= txlen
- << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
+ val |= txlen << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LP_EN;
val |= msg->type << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SHIFT;
writel(val, d->regs + DSI_DIRECT_CMD_MAIN_SETTINGS);
@@ -249,17 +251,36 @@ static ssize_t mcde_dsi_host_transfer(struct
mipi_dsi_host *host,
writel(1, d->regs + DSI_DIRECT_CMD_SEND);
loop_counter = 1000 * 1000 / loop_delay_us;
- while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
-DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
- && --loop_counter)
- usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
-
- if (!loop_counter) {
- dev_err(d->dev, "DSI write timeout!\n");
- return -ETIME;
+ if (MCDE_DSI_HOST_IS_READ(msg->type)) {
+ /* Read command */
+ while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
+(DSI_DIRECT_CMD_STS_READ_COMPLETED |
+ DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR))
+ && --loop_counter)
+ usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
+ if (!loop_counter) {
+ dev_err(d->dev, "DSI write timeout!\n");
+ return -ETIME;
+ }
+ } else {
+ /* Writing only */
+ while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
+DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
+ && --loop_counter)
+ usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
+
+ if (!loop_counter) {
+ dev_err(d->dev, "DSI write timeout!\n");
+ return -ETIME;
+ }
}
val = readl(d->regs + DSI_DIRECT_CMD_STS);
+ if (val & DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR) {
+ dev_err(d->dev, "read completed with error\n");
+ writel(1, d->regs + DSI_DIRECT_CMD_RD_INIT);
+ return -EIO;
+ }
if (val & DSI_DIRECT_CMD_STS_ACKNOWLEDGE_WITH_ERR_RECEIVED) {
val >>= DSI_DIRECT_CMD_STS_ACK_VAL_SHIFT;
dev_err(d->dev, "error during transmission: %04x\n",
@@ -269,10 +290,7 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host
*host,
if (!MCDE_DSI_HOST_IS_READ(msg->type)) {
/* Return number of bytes written */
- if (mipi_dsi_packet_format_is_long(msg->type))
- ret = 4 + txlen;
- else
- ret
[PATCH v4 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
Signed-off-by: Guido Günther
Tested-by: Robert Chiras
---
.../bindings/display/bridge/nwl-dsi.yaml | 176 ++
1 file changed, 176 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
new file mode 100644
index ..31119c7885ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Northwest Logic MIPI-DSI controller on i.MX SoCs
+
+maintainers:
+ - Guido Gúnther
+ - Robert Chiras
+
+description: |
+ NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi bridge
for
+ the SOCs NWL MIPI-DSI host controller.
+
+properties:
+ compatible:
+const: fsl,imx8mq-nwl-dsi
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ clocks:
+items:
+ - description: DSI core clock
+ - description: RX_ESC clock (used in escape mode)
+ - description: TX_ESC clock (used in escape mode)
+ - description: PHY_REF clock
+
+ clock-names:
+items:
+ - const: core
+ - const: rx_esc
+ - const: tx_esc
+ - const: phy_ref
+
+ mux-controls:
+description:
+ mux controller node to use for operating the input mux
+
+ phys:
+maxItems: 1
+description:
+ A phandle to the phy module representing the DPHY
+
+ phy-names:
+items:
+ - const: dphy
+
+ power-domains:
+maxItems: 1
+
+ resets:
+items:
+ - description: dsi byte reset line
+ - description: dsi dpi reset line
+ - description: dsi esc reset line
+ - description: dsi pclk reset line
+
+ reset-names:
+items:
+ - const: byte
+ - const: dpi
+ - const: esc
+ - const: pclk
+
+ ports:
+type: object
+description:
+ A node containing DSI input & output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/graph.txt.
+properties:
+ port@0:
+type: object
+description:
+ Input port node to receive pixel data from the
+ display controller
+
+ port@1:
+type: object
+description:
+ DSI output port node to the panel or the next bridge
+ in the chain
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+required:
+ - '#address-cells'
+ - '#size-cells'
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+patternProperties:
+ "^panel@[0-9]+$":
+type: object
+
+required:
+ - '#address-cells'
+ - '#size-cells'
+ - clock-names
+ - clocks
+ - compatible
+ - interrupts
+ - mux-controls
+ - phy-names
+ - phys
+ - ports
+ - reg
+ - reset-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+
+ mipi_dsi: mipi_dsi@30a0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx8mq-nwl-dsi";
+ reg = <0x30A0 0x300>;
+ clocks = < 163>, < 244>, < 245>, < 164>;
+ clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
+ interrupts = <0 34 4>;
+ mux-controls = < 0>;
+ power-domains = <_mipi>;
+ resets = < 0>, < 1>, < 2>, < 3>;
+ reset-names = "byte", "dpi", "esc", "pclk";
+ phys = <>;
+ phy-names = "dphy";
+
+ panel@0 {
+ compatible = "rocktech,jh057n00900";
+ reg = <0>;
+ port@0 {
+ panel_in: endpoint {
+ remote-endpoint = <_dsi_out>;
+ };
+ };
+ };
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+ mipi_dsi_in: endpoint {
+remote-endpoint = <_mipi_dsi>;
+ };
+};
+port@1 {
+ reg = <1>;
+ mipi_dsi_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+};
+ };
+ };
--
2.23.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/bridge: Add NWL MIPI DSI host controller support
This adds initial support for the NWL MIPI DSI Host controller found on
i.MX8 SoCs.
It adds support for the i.MX8MQ but the same IP can be found on
e.g. the i.MX8QXP.
It has been tested on the Librem 5 devkit using mxsfb.
Signed-off-by: Guido Günther
Co-developed-by: Robert Chiras
Signed-off-by: Robert Chiras
Tested-by: Robert Chiras
---
drivers/gpu/drm/bridge/Kconfig | 2 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/nwl-dsi/Kconfig | 16 +
drivers/gpu/drm/bridge/nwl-dsi/Makefile | 4 +
drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c | 499
drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h | 65 +++
drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c | 699 +++
drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h | 112
8 files changed, 1398 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 1cc9f502c1f2..7980b5c2156f 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -154,6 +154,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
source "drivers/gpu/drm/bridge/adv7511/Kconfig"
+source "drivers/gpu/drm/bridge/nwl-dsi/Kconfig"
+
source "drivers/gpu/drm/bridge/synopsys/Kconfig"
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..d9f6c0f77592 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -16,4 +16,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
new file mode 100644
index ..3b157a9f2229
--- /dev/null
+++ b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
@@ -0,0 +1,16 @@
+config DRM_NWL_MIPI_DSI
+ tristate "Support for Northwest Logic MIPI DSI Host controller"
+ depends on DRM
+ depends on COMMON_CLK
+ depends on OF && HAS_IOMEM
+ select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
+ select DRM_PANEL_BRIDGE
+ select GENERIC_PHY_MIPI_DPHY
+ select MFD_SYSCON
+ select MULTIPLEXER
+ select REGMAP_MMIO
+ help
+ This enables the Northwest Logic MIPI DSI Host controller as
+ for example found on NXP's i.MX8 Processors.
+
diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Makefile
b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
new file mode 100644
index ..804baf2f1916
--- /dev/null
+++ b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+nwl-mipi-dsi-y := nwl-drv.o nwl-dsi.o
+obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-mipi-dsi.o
+header-test-y += nwl-drv.h nwl-dsi.h
diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
new file mode 100644
index ..9ff43d2de127
--- /dev/null
+++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
@@ -0,0 +1,499 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX8 NWL MIPI DSI host driver
+ *
+ * Copyright (C) 2017 NXP
+ * Copyright (C) 2019 Purism SPC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "nwl-drv.h"
+#include "nwl-dsi.h"
+
+#define DRV_NAME "nwl-dsi"
+
+/* Possible platform specific clocks */
+#define NWL_DSI_CLK_CORE "core"
+
+static const struct regmap_config nwl_dsi_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = NWL_DSI_IRQ_MASK2,
+ .name = DRV_NAME,
+};
+
+struct nwl_dsi_platform_data {
+ int (*poweron)(struct nwl_dsi *dsi);
+ int (*poweroff)(struct nwl_dsi *dsi);
+ int (*select_input)(struct nwl_dsi *dsi);
+ int (*deselect_input)(struct nwl_dsi *dsi);
+ struct nwl_dsi_plat_clk_config clk_config[NWL_DSI_MAX_PLATFORM_CLOCKS];
+};
+
+static inline struct nwl_dsi *bridge_to_dsi(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct nwl_dsi, bridge);
+}
+
+static int nwl_dsi_set_platform_clocks(struct nwl_dsi *dsi, bool enable)
+{
+ struct device *dev = dsi->dev;
+ const char *id;
+ struct clk *clk;
+ size_t i;
+ unsigned long rate;
+ int ret, result = 0;
+
+ DRM_DEV_DEBUG_DRIVER(dev, "%s platform clocks\n",
+enable ? "enabling" : "disabling");
+ for (i = 0; i <
[PATCH v4 0/2] drm: bridge: Add NWL MIPI DSI host controller support
This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
SoCs.
It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
I only have imx8mq boards to test I omitted the platform data for other SoCs.
The code is based on NXPs BSP so I added Robert Chiras as
Co-authored-by.
The most notable changes over the BSP driver are
- Calculate HS mode timing from phy_configure_opts_mipi_dphy
- Perform all clock setup via DT
- Merge nwl-imx and nwl drivers
- Add B0 silion revision quirk
- become a bridge driver to hook into mxsfb (from what I read[0] DCSS, which
also can drive the nwl on the imx8mq will likely not become part of
imx-display-subsystem so it makes sense to make it drive a bridge for dsi as
well).
- Use panel_bridge to attach the panel
- Use multiplex framework instead of accessing syscon directly
This has been tested on a Librem 5 devkit using mxsfb with Robert's patches[1]
and the rocktech-jh057n00900 panel driver on next-20190807. The DCSS can later
on also act as input source too.
Changes from v3:
- Per review comments by Robert Chiras
https://lists.freedesktop.org/archives/dri-devel/2019-August/232580.html
- Add Robert's {Signed-off,Tested}-by:
- Respect number of lanes when calculting bandwidth limits
- Drop duplicate NWL_DSI_ENABLE_MULT_PKTS setup
- Per testing by Rober Chiras
https://lists.freedesktop.org/archives/dri-devel/2019-August/233688.html
- Drop duplicate (and too early) drm_bridge_add() in nwl_dir_probe() that
made mxsfb fail to connect to the bridge since the panel_bridge was not up
yet. drm_bridge_add() happens in nwl_dsi_host_attach() after the
panel_bridge was set up.
- Per review comments by Rob Herring on bindings
https://lists.freedesktop.org/archives/dri-devel/2019-August/233196.html
- drop description from power-domains and resets
- allow BSD 2 clause license as well
- make ports more specific
- add #address-cells, #size-cells as required
- use additionalProperties
- panel is of type object
Changes from v2:
- Per review comments by Rob Herring
https://lists.freedesktop.org/archives/dri-devel/2019-August/230448.html
- bindings:
- Simplify by restricting to fsl,imx8mq-nwl-dsi
- document reset lines
- add port@{0,1}
- use a real compatible string for the panel
- resets are required
- Per review comments by Arnd Bergmann
https://lists.freedesktop.org/archives/dri-devel/2019-August/230868.html
- Don't access iomuxc_gpr regs directly. This allows us to drop the
first patch in the series with the iomuxc_gpr field defines.
- Per review comments by Laurent Pinchart
Fix wording in bindings
- Add mux-controls to bindings
- Don't print error message on dphy probe deferral
Changes from v1:
- Per review comments by Sam Ravnborg
https://lists.freedesktop.org/archives/dri-devel/2019-July/228130.html
- Change binding docs to YAML
- build: Don't always visit imx-nwl/
- build: Add header-test-y
- Sort headers according to DRM convention
- Use drm_display_mode instead of videmode
- Per review comments by Fabio Estevam
https://lists.freedesktop.org/archives/dri-devel/2019-July/228299.html
- Don't restrict build to ARCH_MXC
- Drop unused includes
- Drop unreachable code in imx_nwl_dsi_bridge_mode_fixup()
- Drop remaining calls of dev_err() and use DRM_DEV_ERR()
consistently.
- Use devm_platform_ioremap_resource()
- Drop devm_free_irq() in probe() error path
- Use single line comments where sufficient
- Use instead of defining USEC_PER_SEC
- Make input source select imx8 specific
- Drop inclusion (after removal of get_unaligned_le32)
- Drop all EXPORT_SYMBOL_GPL() for functions used in the same module
but different source files.
- Drop nwl_dsi_enable_{rx,tx}_clock() by invoking clk_prepare_enable()
directly
- Remove pointless comment
- Laurent Pinchart
https://lists.freedesktop.org/archives/dri-devel/2019-July/228313.html
https://lists.freedesktop.org/archives/dri-devel/2019-July/228308.html
- Drop (on iMX8MQ) unused csr regmap
- Use NWL_MAX_PLATFORM_CLOCKS everywhere
- Drop get_unaligned_le32() usage
- remove duplicate 'for the' in binding docs
- Don't include unused
- Don't include unused
- Drop dpms_mode for tracking state, trust the drm layer on that
- Use pm_runtime_put() instead of pm_runtime_put_sync()
- Don't overwrite encoder type
- Make imx_nwl_platform_data const
- Use the reset controller API instead of open coding that platform specific
part
- Use intead of making up our own defines
- name mipi_dsi_transfer less generic: nwl_dsi_transfer
- ensure clean in .remove by calling mipi_dsi_host_unregister.
- prefix constants by NWL_DSI_
- properly format transfer_direction enum
- simplify platform clock handling
- Don't modify state in mode_fixup() and use mode_set() instead
- Drop
[Bug 111524] AMD A9 R5 GPU doesn't work after resume
https://bugs.freedesktop.org/show_bug.cgi?id=111524 --- Comment #1 from Alex Deucher --- Please attach your dmesg output and xorg log if using X. -- 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 v3 6/7] drm/amdgpu: utilize subconnector property for DP through atombios
On Thu, Aug 29, 2019 at 08:52:31AM -0400, Alex Deucher wrote:
> On Mon, Aug 26, 2019 at 9:22 AM Oleg Vasilev wrote:
> >
> > Since DP-specific information is stored in driver's structures, every
> > driver needs to implement subconnector property by itself.
> >
> > Reviewed-by: Emil Velikov
> > Signed-off-by: Oleg Vasilev
> > Cc: Alex Deucher
> > Cc: Christian König
> > Cc: David (ChunMing) Zhou
> > Cc: amd-...@lists.freedesktop.org
>
> Similar to Ilia's sentiments, do these make sense for amd drivers? We
> expose the physical connectors only. So physical DP ports show up as
> DP drm connectors and if you connect a passive DP to HDMI/DVI dingle,
> the driver just does the right thing. We don't expose multiple drm
> connectors for the same physical connector.
After a bit more though I guess you could just
if (detected DP)
set_subconnector_prop(DFP type);
else if (detected HDMI)
set_subconnector_prop(HDMI)
>
> Alex
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 10 ++
> > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
> > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 18 +-
> > 3 files changed, 28 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > index ece55c8fa673..348ed9e46bae 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > @@ -26,6 +26,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include "amdgpu.h"
> > @@ -1407,6 +1408,10 @@ amdgpu_connector_dp_detect(struct drm_connector
> > *connector, bool force)
> > pm_runtime_put_autosuspend(connector->dev->dev);
> > }
> >
> > + drm_dp_set_subconnector_property(_connector->base,
> > +ret,
> > +amdgpu_dig_connector->dpcd,
> > +
> > amdgpu_dig_connector->downstream_ports);
> > return ret;
> > }
> >
> > @@ -1934,6 +1939,11 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> > if (has_aux)
> > amdgpu_atombios_dp_aux_init(amdgpu_connector);
> >
> > + if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > + connector_type == DRM_MODE_CONNECTOR_eDP) {
> > +
> > drm_mode_add_dp_subconnector_property(_connector->base);
> > + }
> > +
> > return;
> >
> > failed:
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > index eb9975f4decb..cb360b44371c 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > @@ -469,6 +469,7 @@ struct amdgpu_encoder {
> > struct amdgpu_connector_atom_dig {
> > /* displayport */
> > u8 dpcd[DP_RECEIVER_CAP_SIZE];
> > + u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> > u8 dp_sink_type;
> > int dp_clock;
> > int dp_lane_count;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > index 6858cde9fc5d..b0d414553e71 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > @@ -334,6 +334,22 @@ static void amdgpu_atombios_dp_probe_oui(struct
> > amdgpu_connector *amdgpu_connect
> > buf[0], buf[1], buf[2]);
> > }
> >
> > +static void amdgpu_atombios_dp_ds_ports(struct amdgpu_connector
> > *amdgpu_connector)
> > +{
> > + struct amdgpu_connector_atom_dig *dig_connector =
> > amdgpu_connector->con_priv;
> > + int ret;
> > +
> > + if (dig_connector->dpcd[DP_DPCD_REV] > 0x10) {
> > + ret = drm_dp_dpcd_read(_connector->ddc_bus->aux,
> > + DP_DOWNSTREAM_PORT_0,
> > + dig_connector->downstream_ports,
> > + DP_MAX_DOWNSTREAM_PORTS);
> > + if (ret)
> > + memset(dig_connector->downstream_ports, 0,
> > + DP_MAX_DOWNSTREAM_PORTS);
> > + }
> > +}
> > +
> > int amdgpu_atombios_dp_get_dpcd(struct amdgpu_connector *amdgpu_connector)
> > {
> > struct amdgpu_connector_atom_dig *dig_connector =
> > amdgpu_connector->con_priv;
> > @@ -349,7 +365,7 @@ int amdgpu_atombios_dp_get_dpcd(struct amdgpu_connector
> > *amdgpu_connector)
> > dig_connector->dpcd);
> >
> > amdgpu_atombios_dp_probe_oui(amdgpu_connector);
> > -
> > + amdgpu_atombios_dp_ds_ports(amdgpu_connector);
> > return 0;
> > }
> >
> > --
> > 2.23.0
> >
> > ___
> > amd-gfx mailing list
> > amd-...@lists.freedesktop.org
> >
Re: [PATCH v3 4/7] drm/i915: utilize subconnector property for DP
On Thu, Aug 29, 2019 at 09:09:14AM -0400, Alex Deucher wrote: > On Wed, Aug 28, 2019 at 10:27 AM Ville Syrjälä > wrote: > > > > On Mon, Aug 26, 2019 at 04:22:13PM +0300, Oleg Vasilev wrote: > > > Since DP-specific information is stored in driver's structures, every > > > driver needs to implement subconnector property by itself. > > > > > > v2: updates to match previous commit changes > > > > > > Reviewed-by: Emil Velikov > > > Tested-by: Oleg Vasilev > > > Signed-off-by: Oleg Vasilev > > > Cc: Ville Syrjälä > > > Cc: intel-...@lists.freedesktop.org > > > --- > > > drivers/gpu/drm/i915/display/intel_dp.c | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > > b/drivers/gpu/drm/i915/display/intel_dp.c > > > index 6da6a4859f06..9c97ece803eb 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > > @@ -5434,6 +5434,10 @@ intel_dp_detect(struct drm_connector *connector, > > > if (status != connector_status_connected && !intel_dp->is_mst) > > > intel_dp_unset_edid(intel_dp); > > > > > > + drm_dp_set_subconnector_property(connector, > > > + status, > > > + intel_dp->dpcd, > > > + intel_dp->downstream_ports); > > > return status; > > > } > > > > > > @@ -6332,6 +6336,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, > > > struct drm_connector *connect > > > struct drm_i915_private *dev_priv = to_i915(connector->dev); > > > enum port port = dp_to_dig_port(intel_dp)->base.port; > > > > > > + drm_mode_add_dp_subconnector_property(connector); > > > > Maybe skip this for eDP? > > Not sure if you have something similar, but there are AMD platforms > that contain eDP to LVDS bridges. Then again, probably not a big deal > for the laptop panel. IIRC those don't generally expose the LVDS side as a DFP anyway. Ie. they just looks like a DP device with a local sink. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111241] Shadertoy shader causing hang
https://bugs.freedesktop.org/show_bug.cgi?id=111241 --- Comment #11 from Pierre-Eric Pelloux-Prayer --- (In reply to Dieter Nützel from comment #8) > BTW > > Pierre-Eric can you look into this > > Shadertoy shader corruption, too? > https://www.shadertoy.com/view/Xt3cWS > The "Buffer A" shader doesn't write fragColor when uv.y is < 0.1 or > 0.9. So the content is undefined and may be black on some platform or random. radeonsi is correct here, but we might want to replace undef values with 0x0 to get a default value instead of random. -- 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 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #8 from Johannes Hirte --- For me it's a regression in the 5.2-development. Testing with 5.1-series show no errors. Resume after S3 suspend works without problem. -- 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: [EXT] [PATCH v3 2/2] drm/bridge: Add NWL MIPI DSI host controller support
Hi,
On Thu, Aug 29, 2019 at 09:40:20AM +, Robert Chiras wrote:
> Hi Guido,
>
> One more thing for you to add in v4, see inline.
>
> On Jo, 2019-08-22 at 12:44 +0200, Guido Günther wrote:
> > This adds initial support for the NWL MIPI DSI Host controller found
> > on
> > i.MX8 SoCs.
> >
> > It adds support for the i.MX8MQ but the same IP can be found on
> > e.g. the i.MX8QXP.
> >
> > It has been tested on the Librem 5 devkit using mxsfb.
> >
> > Signed-off-by: Guido Günther
> > Co-developed-by: Robert Chiras
> > ---
> > drivers/gpu/drm/bridge/Kconfig | 2 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/nwl-dsi/Kconfig | 16 +
> > drivers/gpu/drm/bridge/nwl-dsi/Makefile | 4 +
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c | 501
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h | 65 +++
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c | 700
> > +++
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h | 112
> > 8 files changed, 1401 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > b/drivers/gpu/drm/bridge/Kconfig
> > index 1cc9f502c1f2..7980b5c2156f 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -154,6 +154,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
> >
> > source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> >
> > +source "drivers/gpu/drm/bridge/nwl-dsi/Kconfig"
> > +
> > source "drivers/gpu/drm/bridge/synopsys/Kconfig"
> >
> > endmenu
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf5a6f8..d9f6c0f77592 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -16,4 +16,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> > +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi/
> > obj-y += synopsys/
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > new file mode 100644
> > index ..3b157a9f2229
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > @@ -0,0 +1,16 @@
> > +config DRM_NWL_MIPI_DSI
> > + tristate "Support for Northwest Logic MIPI DSI Host
> > controller"
> > + depends on DRM
> > + depends on COMMON_CLK
> > + depends on OF && HAS_IOMEM
> > + select DRM_KMS_HELPER
> > + select DRM_MIPI_DSI
> > + select DRM_PANEL_BRIDGE
> > + select GENERIC_PHY_MIPI_DPHY
> > + select MFD_SYSCON
> > + select MULTIPLEXER
> > + select REGMAP_MMIO
> > + help
> > + This enables the Northwest Logic MIPI DSI Host controller
> > as
> > + for example found on NXP's i.MX8 Processors.
> > +
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > new file mode 100644
> > index ..804baf2f1916
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +nwl-mipi-dsi-y := nwl-drv.o nwl-dsi.o
> > +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-mipi-dsi.o
> > +header-test-y += nwl-drv.h nwl-dsi.h
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > new file mode 100644
> > index ..e457438738c0
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > @@ -0,0 +1,501 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * i.MX8 NWL MIPI DSI host driver
> > + *
> > + * Copyright (C) 2017 NXP
> > + * Copyright (C) 2019 Purism SPC
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "nwl-drv.h"
> > +#include "nwl-dsi.h"
> > +
> > +#define DRV_NAME "nwl-dsi"
> > +
> > +/* Possible platform specific clocks */
> > +#define NWL_DSI_CLK_CORE "core"
> > +
> > +static const struct regmap_config nwl_dsi_regmap_config = {
> > + .reg_bits = 16,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > + .max_register = NWL_DSI_IRQ_MASK2,
> > + .name = DRV_NAME,
> > +};
> > +
> > +struct nwl_dsi_platform_data {
> > + int (*poweron)(struct nwl_dsi *dsi);
> > + int (*poweroff)(struct nwl_dsi *dsi);
> > + int (*select_input)(struct nwl_dsi
[Bug 111211] Kernel 5.2.2+ introduced tearing, corruption and freezes with Raven Ridge 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=111211 Bráulio Barros de Oliveira changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Bráulio Barros de Oliveira --- tearing and crashes were a result of low RAM memory available in conjunction with BTRFS. Switching to EXT4 fixed them, weirdly. -- 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/virtio: Use vmalloc for command buffer allocations.
Hi, > > > - kfree(vbuf->data_buf); > > > + kvfree(vbuf->data_buf); > > > > if (is_vmalloc_addr(vbuf->data_buf)) ... > > > > needed here I gues? > > > > kvfree() handles vmalloc/kmalloc/kvmalloc internally by doing that check. Ok. > - videobuf_vmalloc_to_sg in drivers/media/v4l2-core/videobuf-dma-sg.c, > assumes contiguous array of scatterlist and that the buffer being converted > is page aligned Well, vmalloc memory _is_ page aligned. sg_alloc_table_from_pages() does alot of what you need, you just need a small loop around vmalloc_to_page() create a struct page array beforehand. Completely different approach: use get_user_pages() and don't copy the execbuffer at all. cheers, Gerd
[Bug 111432] [bisected][tonga] Boot failures on agd5f's drm-next branch
https://bugs.freedesktop.org/show_bug.cgi?id=111432 Mike Lothian changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 110949] Continuious warnings from agd5f 5.3-wip branch
https://bugs.freedesktop.org/show_bug.cgi?id=110949 Mike Lothian changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 107922] System Freezes on Raven with agd5f 4.20-wip kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107922 Mike Lothian changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 106999] [raven] 2160p@60Hz no longer available
https://bugs.freedesktop.org/show_bug.cgi?id=106999 Mike Lothian changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #7 from Johannes Hirte --- some more infos: I see the mentioned error in the logs during normal work, but no other problems. When resuming from S3 suspend, the display stays black and I find dozens of those dcn10_verify_allow_pstate_change_high.cold warnings in the log after reboot. Still happens with kernel 5.3-rc6. -- 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 111414] [REGRESSION] [BISECTED] Segmentation fault in si_bind_blend_state after removal of the blend state NULL check
https://bugs.freedesktop.org/show_bug.cgi?id=111414 --- Comment #9 from Michel Dänzer --- (In reply to Dieter Nützel from comment #7) > mpv: ../src/gallium/state_trackers/vdpau/vdpau_private.h:138: > FormatYCBCRToPipe: Assertion `0' failed. > > [...] > > meson ../ --strip --buildtype release ... is fine, too. Assertions are disabled by default for release builds. The assertion failure is still a bug, though a separate one from that reported 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 103217] Recent noveau causes errors with scilab 5.5.2 on NVIDIA G84GL [Quadro FX 570]
https://bugs.freedesktop.org/show_bug.cgi?id=103217 Michel Dänzer changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o |.org|rg QA Contact|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o |.org|rg Component|Drivers/DRI/i915|Drivers/DRI/nouveau -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/2] drm/komeda: Adds layer horizontal input size limitation check for D71
Adds maximum line size check according to the AFBC decoder limitation
and special Line size limitation(2046) for format: YUV420_10BIT and X0L2.
Signed-off-by: Lowry Li (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 49 +++
1 file changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index a56dc56a72fb..41b5bfcbd027 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -401,7 +401,56 @@ static void d71_layer_dump(struct komeda_component *c,
struct seq_file *sf)
seq_printf(sf, "%sAD_V_CROP:\t\t0x%X\n", prefix, v[2]);
}
+static int d71_layer_validate(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+ struct komeda_layer_state *st = to_layer_st(state);
+ struct komeda_layer *layer = to_layer(c);
+ struct drm_plane_state *plane_st;
+ struct drm_framebuffer *fb;
+ u32 fourcc, line_sz, max_line_sz;
+
+ plane_st = drm_atomic_get_new_plane_state(state->obj.state,
+ state->plane);
+ fb = plane_st->fb;
+ fourcc = fb->format->format;
+
+ if (drm_rotation_90_or_270(st->rot))
+ line_sz = st->vsize - st->afbc_crop_t - st->afbc_crop_b;
+ else
+ line_sz = st->hsize - st->afbc_crop_l - st->afbc_crop_r;
+
+ if (fb->modifier) {
+ if ((fb->modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) ==
+ AFBC_FORMAT_MOD_BLOCK_SIZE_32x8)
+ max_line_sz = layer->line_sz;
+ else
+ max_line_sz = layer->line_sz / 2;
+
+ if (line_sz > max_line_sz) {
+ DRM_DEBUG_ATOMIC("afbc request line_sz: %d exceed the
max afbc line_sz: %d.\n",
+line_sz, max_line_sz);
+ return -EINVAL;
+ }
+ }
+
+ if (fourcc == DRM_FORMAT_YUV420_10BIT && line_sz > 2046 &&
(st->afbc_crop_l % 4)) {
+ DRM_DEBUG_ATOMIC("YUV420_10BIT input_hsize: %d exceed the max
size 2046.\n",
+line_sz);
+ return -EINVAL;
+ }
+
+ if (fourcc == DRM_FORMAT_X0L2 && line_sz > 2046 && (st->addr[0] % 16)) {
+ DRM_DEBUG_ATOMIC("X0L2 input_hsize: %d exceed the max size
2046.\n",
+line_sz);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct komeda_component_funcs d71_layer_funcs = {
+ .validate = d71_layer_validate,
.update = d71_layer_update,
.disable= d71_layer_disable,
.dump_register = d71_layer_dump,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/2] drm/komeda: Add line size support
On D71, we are using the global line size. From D32, every
component have a line size register to indicate the fifo size.
So this patch is to set line size support and do the line size
check.
Signed-off-by: Lowry Li (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 56 ---
.../gpu/drm/arm/display/komeda/d71/d71_regs.h | 8 +--
.../drm/arm/display/komeda/komeda_pipeline.h | 2 +
.../display/komeda/komeda_pipeline_state.c| 17 ++
4 files changed, 68 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index c985932954cb..a56dc56a72fb 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -116,6 +116,23 @@ static void dump_block_header(struct seq_file *sf, void
__iomem *reg)
i, hdr.output_ids[i]);
}
+/* On D71, we are using the global line size. From D32, every component have
+ * a line size register to indicate the fifo size.
+ */
+static u32 __get_blk_line_size(struct d71_dev *d71, u32 __iomem *reg,
+ u32 max_default)
+{
+ if (!d71->periph_addr)
+ max_default = malidp_read32(reg, BLK_MAX_LINE_SIZE);
+
+ return max_default;
+}
+
+static u32 get_blk_line_size(struct d71_dev *d71, u32 __iomem *reg)
+{
+ return __get_blk_line_size(d71, reg, d71->max_line_size);
+}
+
static u32 to_rot_ctrl(u32 rot)
{
u32 lr_ctrl = 0;
@@ -423,7 +440,27 @@ static int d71_layer_init(struct d71_dev *d71,
layer->color_mgr.fgamma_mgr = d71->glb_lt_mgr;
}
- set_range(>hsize_in, 4, d71->max_line_size);
+ if (!d71->periph_addr) {
+ /* D32 or newer product */
+ layer->line_sz = malidp_read32(reg, BLK_MAX_LINE_SIZE);
+ layer->yuv_line_sz = L_INFO_YUV_MAX_LINESZ(layer_info);
+ } else if (d71->max_line_size > 2048) {
+ /* D71 4K */
+ layer->line_sz = d71->max_line_size;
+ layer->yuv_line_sz = layer->line_sz / 2;
+ } else {
+ /* D71 2K */
+ if (layer->layer_type == KOMEDA_FMT_RICH_LAYER) {
+ /* rich layer is 4K configuration */
+ layer->line_sz = d71->max_line_size * 2;
+ layer->yuv_line_sz = layer->line_sz / 2;
+ } else {
+ layer->line_sz = d71->max_line_size;
+ layer->yuv_line_sz = 0;
+ }
+ }
+
+ set_range(>hsize_in, 4, layer->line_sz);
set_range(>vsize_in, 4, d71->max_vsize);
malidp_write32(reg, LAYER_PALPHA, D71_PALPHA_DEF_MAP);
@@ -676,9 +713,11 @@ static int d71_wb_layer_init(struct d71_dev *d71,
wb_layer = to_layer(c);
wb_layer->layer_type = KOMEDA_FMT_WB_LAYER;
+ wb_layer->line_sz = get_blk_line_size(d71, reg);
+ wb_layer->yuv_line_sz = wb_layer->line_sz;
- set_range(_layer->hsize_in, D71_MIN_LINE_SIZE, d71->max_line_size);
- set_range(_layer->vsize_in, D71_MIN_VERTICAL_SIZE, d71->max_vsize);
+ set_range(_layer->hsize_in, 64, wb_layer->line_sz);
+ set_range(_layer->vsize_in, 64, d71->max_vsize);
return 0;
}
@@ -822,8 +861,8 @@ static int d71_compiz_init(struct d71_dev *d71,
if (komeda_product_match(d71->mdev, MALIDP_D77_PRODUCT_ID))
compiz->support_channel_scaling = true;
- set_range(>hsize, D71_MIN_LINE_SIZE, d71->max_line_size);
- set_range(>vsize, D71_MIN_VERTICAL_SIZE, d71->max_vsize);
+ set_range(>hsize, 64, get_blk_line_size(d71, reg));
+ set_range(>vsize, 64, d71->max_vsize);
return 0;
}
@@ -980,7 +1019,7 @@ static int d71_scaler_init(struct d71_dev *d71,
}
scaler = to_scaler(c);
- set_range(>hsize, 4, 2048);
+ set_range(>hsize, 4, __get_blk_line_size(d71, reg, 2048));
set_range(>vsize, 4, 4096);
scaler->max_downscaling = 6;
scaler->max_upscaling = 64;
@@ -1089,7 +1128,7 @@ static int d71_splitter_init(struct d71_dev *d71,
splitter = to_splitter(c);
- set_range(>hsize, 4, d71->max_line_size);
+ set_range(>hsize, 4, get_blk_line_size(d71, reg));
set_range(>vsize, 4, d71->max_vsize);
return 0;
@@ -1240,7 +1279,8 @@ static int d71_merger_init(struct d71_dev *d71,
merger = to_merger(c);
- set_range(>hsize_merged, 4, 4032);
+ set_range(>hsize_merged, 4,
+ __get_blk_line_size(d71, reg, 4032));
set_range(>vsize_merged, 4, 4096);
return 0;
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
index c1be4594bc92..a58389e623bb 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
+++
[PATCH v1 0/2] drm/komeda: Add layer line size support
Hi, From D32 every component have a line size register to indicate internal fifo size, instead of using the global line_sz. This serie aims at adding the layer line size support and check accordingly on both D71 and D32 or newer. Lowry Li (Arm Technology China) (2): drm/komeda: Add line size support drm/komeda: Adds layer horizontal input size limitation check for D71 .../arm/display/komeda/d71/d71_component.c| 105 -- .../gpu/drm/arm/display/komeda/d71/d71_regs.h | 8 +- .../drm/arm/display/komeda/komeda_pipeline.h | 2 + .../display/komeda/komeda_pipeline_state.c| 17 +++ 4 files changed, 117 insertions(+), 15 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/mediatek: Only block updates to CRTCs that have a pending update
Hi, Bibby:
On Fri, 2019-08-30 at 15:38 +0800, Bibby Hsieh wrote:
> Currently we use a single mutex to allow only a single atomic
> update at a time. In truth, though, we really only want to
> ensure that only a single atomic update is allowed per CRTC.
>
> In other words, for each atomic update, we only block if there
> is a pending update for the CRTCs involved, and don't block if
> there are only pending updates for other CRTCs.
I don't know why this patch is so complicated. The original problem is
that one mutex for whole drm would block different crtc. So I think each
crtc has its own mutex would solve this problem and we need not the
event waiting. Do I miss something?
Regards,
CK
>
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
>
> Signed-off-by: Daniel Kurtz
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 14 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 182 +---
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 12 +-
> 3 files changed, 184 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index b55970a2869d..7697b40baac0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -45,6 +46,8 @@ struct mtk_drm_crtc {
> struct mtk_disp_mutex *mutex;
> unsigned intddp_comp_nr;
> struct mtk_ddp_comp **ddp_comp;
> +
> + struct drm_crtc_state *old_crtc_state;
> };
>
> struct mtk_crtc_state {
> @@ -343,6 +346,7 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
> *mtk_crtc)
> static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> {
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + struct drm_atomic_state *atomic_state = mtk_crtc->old_crtc_state->state;
> struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> unsigned int i;
> @@ -382,6 +386,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> }
> }
> mtk_crtc->pending_planes = false;
> + mtk_atomic_state_put_queue(atomic_state);
> }
> }
>
> @@ -451,6 +456,7 @@ static void mtk_drm_crtc_atomic_begin(struct drm_crtc
> *crtc,
> static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> struct drm_crtc_state *old_crtc_state)
> {
> + struct drm_atomic_state *old_atomic_state = old_crtc_state->state;
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> struct mtk_drm_private *priv = crtc->dev->dev_private;
> unsigned int pending_planes = 0;
> @@ -469,8 +475,13 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
> *crtc,
> pending_planes |= BIT(i);
> }
> }
> - if (pending_planes)
> +
> + if (pending_planes) {
> mtk_crtc->pending_planes = true;
> + drm_atomic_state_get(old_atomic_state);
> + mtk_crtc->old_crtc_state = old_crtc_state;
> + }
> +
> if (crtc->state->color_mgmt_changed)
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> @@ -526,6 +537,7 @@ static int mtk_drm_crtc_init(struct drm_device *drm,
>
> void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *comp)
> {
> +
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> struct mtk_drm_private *priv = crtc->dev->dev_private;
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index c0928b69dc43..b0308a3a7483 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -31,11 +31,120 @@
> #define DRIVER_MAJOR 1
> #define DRIVER_MINOR 0
>
> -static void mtk_atomic_schedule(struct mtk_drm_private *private,
> +struct mtk_atomic_state {
> + struct drm_atomic_state base;
> + struct list_head list;
> + struct work_struct work;
> +};
> +
> +static inline struct mtk_atomic_state *to_mtk_state(struct drm_atomic_state
> *s)
> +{
> + return container_of(s, struct mtk_atomic_state, base);
> +}
> +
> +void mtk_atomic_state_put_queue(struct drm_atomic_state *state)
> +{
> + struct drm_device *drm = state->dev;
> + struct mtk_drm_private *mtk_drm = drm->dev_private;
> + struct mtk_atomic_state *mtk_state = to_mtk_state(state);
> + unsigned long flags;
> +
> + spin_lock_irqsave(_drm->unreference.lock, flags);
> + list_add_tail(_state->list, _drm->unreference.list);
> + spin_unlock_irqrestore(_drm->unreference.lock, flags);
> +
> + schedule_work(_drm->unreference.work);
> +}
> +
> +static uint32_t
Re: [PATCH] drm/ingenic: Hardcode panel type to DPI
Hi Sam, Laurent,
Le mar. 27 août 2019 à 7:00, Sam Ravnborg a écrit
:
On Fri, Aug 23, 2019 at 11:30:09PM +0200, Paul Cercueil wrote:
Hi Laurent,
Le ven. 23 août 2019 à 23:23, Laurent Pinchart
a écrit :
> The ingenic driver supports DPI panels only at the moment, so
hardcode
> their type to DPI instead of Unknown.
>
> Signed-off-by: Laurent Pinchart
> ---
> Paul, as the driver has been merged in v5.3-rc1, this is a
candidate for
> a v5.3 fix. Keeping the connector type as unknown could cause a
> userspace dependency on it, preventing it from being changed
later.
Makes sense.
Reviewed-by: Paul Cercueil
In another mail we discuss CONNECTOR_PANEL. But we should not hold up
due to this.
Reviewed-by: Sam Ravnborg
Paul - will you apply to drm-misc-fixes?
I pushed to drm-misc-next (I hope that's OK and I didn't screw up) and
also drm-misc-fixes.
Thanks,
-Paul
Sam
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
> b/drivers/gpu/drm/ingenic/ingenic-drm.c
> index ce1fae3a78a9..2e2ed653e9c6 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
> @@ -675,10 +675,9 @@ static int ingenic_drm_probe(struct
platform_device
> *pdev)
> return ret;
> }
>
> - if (panel) {
> + if (panel)
> bridge = devm_drm_panel_bridge_add(dev, panel,
> -DRM_MODE_CONNECTOR_Unknown);
> - }
> +DRM_MODE_CONNECTOR_DPI);
>
> priv->dma_hwdesc = dma_alloc_coherent(dev,
sizeof(*priv->dma_hwdesc),
> >dma_hwdesc_phys,
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5, 07/32] drm/mediatek: add mutex mod into ddp private data
From: Yongqiang Niu
except mutex mod, mutex mod reg,mutex sof reg,
and mutex sof id will be ddp private data
Signed-off-by: Yongqiang Niu
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 41 +-
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8106a71..b6cc3d8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -139,12 +139,16 @@ struct mtk_disp_mutex {
bool claimed;
};
+struct mtk_ddp_data {
+ const unsigned int *mutex_mod;
+};
+
struct mtk_ddp {
struct device *dev;
struct clk *clk;
void __iomem*regs;
struct mtk_disp_mutex mutex[10];
- const unsigned int *mutex_mod;
+ const struct mtk_ddp_data *data;
};
static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
@@ -194,6 +198,18 @@ struct mtk_ddp {
[DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
};
+static const struct mtk_ddp_data mt2701_ddp_driver_data = {
+ .mutex_mod = mt2701_mutex_mod,
+};
+
+static const struct mtk_ddp_data mt2712_ddp_driver_data = {
+ .mutex_mod = mt2712_mutex_mod,
+};
+
+static const struct mtk_ddp_data mt8173_ddp_driver_data = {
+ .mutex_mod = mt8173_mutex_mod,
+};
+
static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next,
unsigned int *addr)
@@ -456,15 +472,15 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
reg = MUTEX_SOF_DPI1;
break;
default:
- if (ddp->mutex_mod[id] < 32) {
+ if (ddp->data->mutex_mod[id] < 32) {
offset = DISP_REG_MUTEX_MOD(mutex->id);
reg = readl_relaxed(ddp->regs + offset);
- reg |= 1 << ddp->mutex_mod[id];
+ reg |= 1 << ddp->data->mutex_mod[id];
writel_relaxed(reg, ddp->regs + offset);
} else {
offset = DISP_REG_MUTEX_MOD2(mutex->id);
reg = readl_relaxed(ddp->regs + offset);
- reg |= 1 << (ddp->mutex_mod[id] - 32);
+ reg |= 1 << (ddp->data->mutex_mod[id] - 32);
writel_relaxed(reg, ddp->regs + offset);
}
return;
@@ -494,15 +510,15 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
*mutex,
ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
break;
default:
- if (ddp->mutex_mod[id] < 32) {
+ if (ddp->data->mutex_mod[id] < 32) {
offset = DISP_REG_MUTEX_MOD(mutex->id);
reg = readl_relaxed(ddp->regs + offset);
- reg &= ~(1 << ddp->mutex_mod[id]);
+ reg &= ~(1 << ddp->data->mutex_mod[id]);
writel_relaxed(reg, ddp->regs + offset);
} else {
offset = DISP_REG_MUTEX_MOD2(mutex->id);
reg = readl_relaxed(ddp->regs + offset);
- reg &= ~(1 << (ddp->mutex_mod[id] - 32));
+ reg &= ~(1 << (ddp->data->mutex_mod[id] - 32));
writel_relaxed(reg, ddp->regs + offset);
}
break;
@@ -577,7 +593,7 @@ static int mtk_ddp_probe(struct platform_device *pdev)
return PTR_ERR(ddp->regs);
}
- ddp->mutex_mod = of_device_get_match_data(dev);
+ ddp->data = of_device_get_match_data(dev);
platform_set_drvdata(pdev, ddp);
@@ -590,9 +606,12 @@ static int mtk_ddp_remove(struct platform_device *pdev)
}
static const struct of_device_id ddp_driver_dt_match[] = {
- { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
- { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
- { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
+ { .compatible = "mediatek,mt2701-disp-mutex",
+ .data = _ddp_driver_data},
+ { .compatible = "mediatek,mt2712-disp-mutex",
+ .data = _ddp_driver_data},
+ { .compatible = "mediatek,mt8173-disp-mutex",
+ .data = _ddp_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, ddp_driver_dt_match);
--
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/modes: Fix the command line parser to take force options into account
Hi!
Dne torek, 27. avgust 2019 ob 13:58:48 CEST je Maxime Ripard napisal(a):
> From: Maxime Ripard
>
> The command line parser when it has been rewritten introduced a regression
> when the only thing on the command line is an option to force the detection
> of a connector (such as video=HDMI-A-1:d), which are completely valid.
>
> It's been further broken by the support for the named modes which take
> anything that is not a resolution as a named mode.
>
> Let's fix this by running the extra command line option parser on the named
> modes if they only take a single character.
>
> Fixes: e08ab74bd4c7 ("drm/modes: Rewrite the command line parser")
> Reported-by: Jernej Škrabec
> Reported-by: Thomas Graichen
> Signed-off-by: Maxime Ripard
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: gnome-shell stuck because of amdgpu driver [5.3 RC5]
On Fri, 30 Aug 2019 06:04:06 +0800 Mikhail Gavrilov wrote: > On Sun, Aug 25, 2019 at 10:13:05PM +0800, Hillf Danton wrote: > > Can we try to add the fallback timer manually? > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > > @@ -322,6 +322,10 @@ int amdgpu_fence_wait_empty(struct amdgp > > } > > rcu_read_unlock(); > > > > + if (!timer_pending(>fence_drv.fallback_timer)) > > + mod_timer(>fence_drv.fallback_timer, > > + jiffies + (AMDGPU_FENCE_JIFFIES_TIMEOUT << 1)); > > + > > r = dma_fence_wait(fence, false); > > dma_fence_put(fence); > > return r; > > -- > > > > Or simply wait with an ear on signal and timeout if adding timer > > seems to go a bit too far? > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > > @@ -322,7 +322,12 @@ int amdgpu_fence_wait_empty(struct amdgp > > } > > rcu_read_unlock(); > > > > - r = dma_fence_wait(fence, false); > > + if (0 < dma_fence_wait_timeout(fence, true, > > + AMDGPU_FENCE_JIFFIES_TIMEOUT + > > + (AMDGPU_FENCE_JIFFIES_TIMEOUT >> 3))) > > + r = 0; > > + else > > + r = -EINVAL; > > dma_fence_put(fence); WARN(r, "gnome shell stuck warning\n"); > > return r; > > } > > I tested both patches on top of 5.3 RC6. Each patch I was tested more > than 24 hours and I don't seen any regressions or problems with them. > Add a warning to show if it makes sense in field: neither regression nor problem will have been observed with the warning printed. Thanks Hillf ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 11/14] drm/mxsfb: Improve the axi clock usage
Currently, the enable of the axi clock return status is ignored, causing
issues when the enable fails then we try to disable it. Therefore, it is
better to check the return status and disable it only when enable
succeeded.
Also, remove the helper functions around clk_axi, since we can directly
use the clk API function for enable/disable the clock. Those functions
are already checking for NULL clk and returning 0 if that's the case.
Signed-off-by: Robert Chiras
Acked-by: Leonard Crestez
Tested-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 8
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 32 +---
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 3 ---
3 files changed, 17 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index a4ba368..e727f5e 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -408,7 +408,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
{
dma_addr_t paddr;
- mxsfb_enable_axi_clk(mxsfb);
+ clk_prepare_enable(mxsfb->clk_axi);
writel(0, mxsfb->base + LCDC_CTRL);
mxsfb_crtc_mode_set_nofb(mxsfb);
@@ -425,7 +425,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
{
mxsfb_disable_controller(mxsfb);
- mxsfb_disable_axi_clk(mxsfb);
+ clk_disable_unprepare(mxsfb->clk_axi);
}
void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
@@ -451,8 +451,8 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private
*mxsfb,
paddr = mxsfb_get_fb_paddr(mxsfb);
if (paddr) {
- mxsfb_enable_axi_clk(mxsfb);
+ clk_prepare_enable(mxsfb->clk_axi);
writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
- mxsfb_disable_axi_clk(mxsfb);
+ clk_disable_unprepare(mxsfb->clk_axi);
}
}
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index d8686c7..888b520 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -94,18 +94,6 @@ drm_pipe_to_mxsfb_drm_private(struct drm_simple_display_pipe
*pipe)
return container_of(pipe, struct mxsfb_drm_private, pipe);
}
-void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
-{
- if (mxsfb->clk_axi)
- clk_prepare_enable(mxsfb->clk_axi);
-}
-
-void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
-{
- if (mxsfb->clk_axi)
- clk_disable_unprepare(mxsfb->clk_axi);
-}
-
/**
* mxsfb_atomic_helper_check - validate state object
* @dev: DRM device
@@ -265,25 +253,31 @@ static void mxsfb_pipe_update(struct
drm_simple_display_pipe *pipe,
static int mxsfb_pipe_enable_vblank(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ int ret = 0;
+
+ ret = clk_prepare_enable(mxsfb->clk_axi);
+ if (ret)
+ return ret;
/* Clear and enable VBLANK IRQ */
- mxsfb_enable_axi_clk(mxsfb);
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_SET);
- mxsfb_disable_axi_clk(mxsfb);
+ clk_disable_unprepare(mxsfb->clk_axi);
- return 0;
+ return ret;
}
static void mxsfb_pipe_disable_vblank(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ if (clk_prepare_enable(mxsfb->clk_axi))
+ return;
+
/* Disable and clear VBLANK IRQ */
- mxsfb_enable_axi_clk(mxsfb);
writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_CLR);
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
- mxsfb_disable_axi_clk(mxsfb);
+ clk_disable_unprepare(mxsfb->clk_axi);
}
static struct drm_simple_display_pipe_funcs mxsfb_funcs = {
@@ -444,7 +438,7 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
struct mxsfb_drm_private *mxsfb = drm->dev_private;
u32 reg;
- mxsfb_enable_axi_clk(mxsfb);
+ clk_prepare_enable(mxsfb->clk_axi);
reg = readl(mxsfb->base + LCDC_CTRL1);
@@ -453,7 +447,7 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
- mxsfb_disable_axi_clk(mxsfb);
+ clk_disable_unprepare(mxsfb->clk_axi);
return IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index a178173..54c0644 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -39,9 +39,6 @@ struct mxsfb_drm_private {
int mxsfb_setup_crtc(struct drm_device *dev);
int mxsfb_create_output(struct drm_device *dev);
-void
[PATCH] drm/amd/powerplay: Variable ps could be NULL when it get dereferenced
Inside function cz_get_performance_level(), pointer ps could be NULL via cast_const_PhwCzPowerState(). However, this pointer is dereferenced without any check, which is potentially unsafe. Signed-off-by: Yizhuo --- drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c index bc839ff0bdd0..d2628e7b612d 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c @@ -1799,6 +1799,9 @@ static int cz_get_performance_level(struct pp_hwmgr *hwmgr, const struct pp_hw_p data = (struct cz_hwmgr *)(hwmgr->backend); ps = cast_const_PhwCzPowerState(state); + if (!ps) + return -EINVAL; + level_index = index > ps->level - 1 ? ps->level - 1 : index; level->coreClock = ps->levels[level_index].engineClock; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 14/14] drm/mxsfb: Add support for live pixel format change
This IP requires full stop and re-start when changing display timings,
but we can change the pixel format while running.
Signed-off-by: Robert Chiras
Tested-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 317575e..5607fc0 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -494,6 +494,7 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private
*mxsfb,
struct drm_crtc *crtc = >crtc;
struct drm_plane_state *new_state = pipe->plane.state;
struct drm_framebuffer *fb = pipe->plane.state->fb;
+ struct drm_framebuffer *old_fb = state->fb;
struct drm_pending_vblank_event *event;
u32 fb_addr, src_off, src_w, stride, cpp = 0;
@@ -510,7 +511,7 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private
*mxsfb,
}
spin_unlock_irq(>dev->event_lock);
- if (!fb)
+ if (!fb || !old_fb)
return;
fb_addr = mxsfb_get_fb_paddr(mxsfb);
@@ -533,4 +534,17 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private
*mxsfb,
src_w = new_state->src_w >> 16;
mxsfb_set_fb_hcrop(mxsfb, src_w, stride);
}
+
+ if (old_fb->format->format != fb->format->format) {
+ struct drm_format_name_buf old_fmt_buf;
+ struct drm_format_name_buf new_fmt_buf;
+
+ DRM_DEV_DEBUG_DRIVER(crtc->dev->dev,
+ "Switching pixel format: %s -> %s\n",
+ drm_get_format_name(old_fb->format->format,
+ _fmt_buf),
+ drm_get_format_name(fb->format->format,
+ _fmt_buf));
+ mxsfb_set_pixel_fmt(mxsfb, true);
+ }
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/39] put_user_pages(): miscellaneous call sites
Hi John... I added this patch series on top of Linux 5.3rc6 and ran xfstests with no regressions... Acked-by: Mike Marshall -Mike On Tue, Aug 6, 2019 at 9:50 PM John Hubbard wrote: > > On 8/6/19 6:32 PM, john.hubb...@gmail.com wrote: > > From: John Hubbard > > ... > > > > John Hubbard (38): > > mm/gup: add make_dirty arg to put_user_pages_dirty_lock() > ... > > 54 files changed, 191 insertions(+), 323 deletions(-) > > > ahem, yes, apparently this is what happens if I add a few patches while > editing > the cover letter... :) > > The subject line should read "00/41", and the list of files affected here is > therefore under-reported in this cover letter. However, the patch series > itself is > intact and ready for submission. > > thanks, > -- > John Hubbard > NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5, 19/32] drm/medaitek: add layer_nr for ovl private data
From: Yongqiang Niu
This patch add layer_nr for ovl private data
ovl_2l almost same with with ovl hardware, except the
layer number for ovl_2l is 2 and ovl is 4.
this patch is a preparation for ovl-2l and
ovl share the same driver.
Signed-off-by: Yongqiang Niu
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 82eaefd..baef066 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -52,6 +52,7 @@
struct mtk_disp_ovl_data {
unsigned int addr;
unsigned int gmc_bits;
+ unsigned int layer_nr;
bool fmt_rgb565_is_0;
};
@@ -129,7 +130,9 @@ static void mtk_ovl_config(struct mtk_ddp_comp *comp,
unsigned int w,
static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp *comp)
{
- return 4;
+ struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
+
+ return ovl->data->layer_nr;
}
static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx)
@@ -334,12 +337,14 @@ static int mtk_disp_ovl_remove(struct platform_device
*pdev)
static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT2701,
.gmc_bits = 8,
+ .layer_nr = 4,
.fmt_rgb565_is_0 = false,
};
static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT8173,
.gmc_bits = 8,
+ .layer_nr = 4,
.fmt_rgb565_is_0 = true,
};
--
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/modes: Introduce a whitelist for the named modes
Hi!
Dne torek, 27. avgust 2019 ob 13:58:49 CEST je Maxime Ripard napisal(a):
> From: Maxime Ripard
>
> The named modes support has introduced a number of glitches that were in
> part due to the fact that the parser will take any string as a named mode.
>
> Since we shouldn't have a lot of options there (and they should be pretty
> standard), let's introduce a whitelist of the available named modes so that
> the kernel can differentiate between a poorly formed command line and a
> named mode.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_modes.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index ea7e6c8c8318..988797d8080a 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1677,6 +1677,22 @@ static int drm_mode_parse_cmdline_options(char *str,
> size_t len, return 0;
> }
>
> +const char *drm_named_modes_whitelist[] = {
> + "NTSC",
> + "PAL",
> +};
That array should be static. With that fixed:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> +
> +static bool drm_named_mode_is_in_whitelist(const char *mode, unsigned int
> size) +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++)
> + if (!strncmp(mode, drm_named_modes_whitelist[i], size))
> + return true;
> +
> + return false;
> +}
> +
> /**
> * drm_mode_parse_command_line_for_connector - parse command line modeline
> for connector * @mode_option: optional per connector mode option
> @@ -1794,6 +1810,10 @@ bool drm_mode_parse_command_line_for_connector(const
> char *mode_option, if (named_mode) {
> if (mode_end + 1 > DRM_DISPLAY_MODE_LEN)
> return false;
> +
> + if (!drm_named_mode_is_in_whitelist(name, mode_end))
> + return false;
> +
> strscpy(mode->name, name, mode_end + 1);
> } else {
> ret = drm_mode_parse_cmdline_res_mode(name, mode_end,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5, 02/32] dt-bindings: mediatek: add ovl_2l description for mt8183 display
From: Yongqiang Niu Update device tree binding documention for the display subsystem for Mediatek MT8183 SOCs Signed-off-by: Yongqiang Niu Reviewed-by: Rob Herring --- .../bindings/display/mediatek/mediatek,disp.txt| 27 +++--- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index 464b92f..8c4700f 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -27,19 +27,20 @@ Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt. Required properties (all function blocks): - compatible: "mediatek,-disp-", one of - "mediatek,-disp-ovl" - overlay (4 layers, blending, csc) - "mediatek,-disp-rdma" - read DMA / line buffer - "mediatek,-disp-wdma" - write DMA - "mediatek,-disp-color" - color processor - "mediatek,-disp-aal" - adaptive ambient light controller - "mediatek,-disp-gamma" - gamma correction - "mediatek,-disp-merge" - merge streams from two RDMA sources - "mediatek,-disp-split" - split stream to two encoders - "mediatek,-disp-ufoe" - data compression engine - "mediatek,-dsi"- DSI controller, see mediatek,dsi.txt - "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt - "mediatek,-disp-mutex" - display mutex - "mediatek,-disp-od"- overdrive + "mediatek,-disp-ovl" - overlay (4 layers, blending, csc) + "mediatek,-disp-ovl-2l" - overlay (2 layers, blending, csc) + "mediatek,-disp-rdma" - read DMA / line buffer + "mediatek,-disp-wdma" - write DMA + "mediatek,-disp-color"- color processor + "mediatek,-disp-aal" - adaptive ambient light controller + "mediatek,-disp-gamma"- gamma correction + "mediatek,-disp-merge"- merge streams from two RDMA sources + "mediatek,-disp-split"- split stream to two encoders + "mediatek,-disp-ufoe" - data compression engine + "mediatek,-dsi" - DSI controller, see mediatek,dsi.txt + "mediatek,-dpi" - DPI controller, see mediatek,dpi.txt + "mediatek,-disp-mutex"- display mutex + "mediatek,-disp-od" - overdrive the supported chips are mt2701, mt2712 and mt8173. - reg: Physical base address and length of the function block register space - interrupts: The interrupt signal from the function block (required, except for -- 1.8.1.1.dirty ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/39] put_user_pages(): miscellaneous call sites
On 8/29/2019 6:29 PM, Mike Marshall wrote: Hi John... I added this patch series on top of Linux 5.3rc6 and ran xfstests with no regressions... Acked-by: Mike Marshall Hi Mike (and I hope Ira and others are reading as well, because I'm making a bunch of claims further down), That's great news, thanks for running that test suite and for the report and the ACK. There is an interesting pause right now, due to the fact that we've made some tentative decisions about gup pinning, that affect the call sites. A key decision is that only pages that were requested via FOLL_PIN, will require put_user_page*() to release them. There are 4 main cases, which were first explained by Jan Kara and Vlastimil Babka, and are now written up in my FOLL_PIN patch [1]. So, what that means for this series is that: 1. Some call sites (mlock.c for example, and a lot of the mm/ files in fact, and more) will not be converted: some of these patches will get dropped, especially in mm/. 2. Call sites that do DirectIO or RDMA will need to set FOLL_PIN, and will also need to call put_user_page(). 3. Call sites that do RDMA will need to set FOLL_LONGTERM *and* FOLL_PIN, 3.a. ...and will at least in some cases need to provide a link to a vaddr_pin object, and thus back to a struct file*...maybe. Still under discussion. 4. It's desirable to keep FOLL_* flags (or at least FOLL_PIN) internal to the gup() calls. That implies using a wrapper call such as Ira's vaddr_pin_[user]_pages(), instead of gup(), and vaddr_unpin_[user]_pages() instead of put_user_page*(). 5. We don't want to churn the call sites unnecessarily. With that in mind, I've taken another pass through all these patches and narrowed it down to: a) 12 call sites that I'd like to convert soon, but even those really look cleaner with a full conversion to a wrapper call similar to (identical to?) vaddr_pin_[user]_pages(), probably just the FOLL_PIN only variant (not FOLL_LONGTERM). That wrapper call is not ready yet, though. b) Some more call sites that require both FOLL_PIN and FOLL_LONGTERM. Definitely will wait to use the wrapper calls for these, because they may also require hooking up to a struct file*. c) A few more that were already applied, which is fine, because they show where to convert, and simplify a few sites anyway. But they'll need follow-on changes to, one way or another, set FOLL_PIN. d) And of course a few sites whose patches get dropped, as mentioned above. [1] https://lore.kernel.org/r/20190821040727.19650-3-jhubb...@nvidia.com thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/modes: Add a switch to differentiate free standing options
Hi!
Dne torek, 27. avgust 2019 ob 13:58:47 CEST je Maxime Ripard napisal(a):
> From: Maxime Ripard
>
> Some extra command line options can be either specified without anything
> else on the command line (basically all the force connection options), but
> some other are only relevant when matched with a resolution (margin and
> interlace).
>
> Let's add a switch to restrict if needed the available option set.
>
> Fixes: e08ab74bd4c7 ("drm/modes: Rewrite the command line parser")
> Signed-off-by: Maxime Ripard
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5, 30/32] drm/mediatek: add connection from DITHER0 to DSI0
From: Yongqiang Niu
This patch add connection from DITHER0 to DSI0
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 237824f..fd38658 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -35,10 +35,12 @@
#define MT8183_DISP_OVL0_2L_MOUT_EN0xf04
#define MT8183_DISP_OVL1_2L_MOUT_EN0xf08
+#define MT8183_DISP_DITHER0_MOUT_EN0xf0c
#define MT8183_DISP_PATH0_SEL_IN 0xf24
#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
+#define DITHER0_MOUT_IN_DSI0 BIT(0)
#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
#define MT2701_DISP_MUTEX0_MOD00x2c
@@ -323,6 +325,9 @@ static unsigned int mtk_ddp_mout_en(const struct
mtk_mmsys_reg_data *data,
next == DDP_COMPONENT_RDMA1) {
*addr = MT8183_DISP_OVL1_2L_MOUT_EN;
value = OVL1_2L_MOUT_EN_RDMA1;
+ } else if (cur == DDP_COMPONENT_DITHER && next == DDP_COMPONENT_DSI0) {
+ *addr = MT8183_DISP_DITHER0_MOUT_EN;
+ value = DITHER0_MOUT_IN_DSI0;
} else {
value = 0;
}
--
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/selftests: modes: Add more unit tests for the cmdline parser
Hi! Dne torek, 27. avgust 2019 ob 13:58:50 CEST je Maxime Ripard napisal(a): > From: Maxime Ripard > > Let's add some unit tests for the recent bugs we just fixed. > > Signed-off-by: Maxime Ripard > --- > .../gpu/drm/selftests/drm_cmdline_selftests.h | 7 + > .../drm/selftests/test-drm_cmdline_parser.c | 130 ++ > 2 files changed, 137 insertions(+) > > diff --git a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h > b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h index Reviewed-by: Jernej Skrabec Best regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5, 13/32] drm/mediatek: move rdma sout from mtk_ddp_mout_en into mtk_ddp_sout_sel
From: Yongqiang Niu
This patch move rdma sout from mtk_ddp_mout_en into mtk_ddp_sout_sel
rdma only has single output, but no multi output,
all these rdma->dsi/dpi usecase should move to mtk_ddp_sout_sel
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 90 +-
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 338cc2f..a5a6689 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -299,51 +299,6 @@ static unsigned int mtk_ddp_mout_en(const struct
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD1_MOUT_EN_RDMA1;
- } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
- value = RDMA0_SOUT_DPI0;
- } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
- value = RDMA0_SOUT_DPI1;
- } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
- value = RDMA0_SOUT_DSI1;
- } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
- value = RDMA0_SOUT_DSI2;
- } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
- value = RDMA0_SOUT_DSI3;
- } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
- value = RDMA1_SOUT_DSI1;
- } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
- value = RDMA1_SOUT_DSI2;
- } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
- value = RDMA1_SOUT_DSI3;
- } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
- *addr = data->rdma1_sout_sel_in;
- value = data->rdma1_sout_dpi0;
- } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
- value = RDMA1_SOUT_DPI1;
- } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
- *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
- value = RDMA2_SOUT_DPI0;
- } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
- value = RDMA2_SOUT_DPI1;
- } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
- value = RDMA2_SOUT_DSI1;
- } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
- *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
- value = RDMA2_SOUT_DSI2;
- } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
- *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
- value = RDMA2_SOUT_DSI3;
} else {
value = 0;
}
@@ -423,6 +378,51 @@ static unsigned int mtk_ddp_sout_sel(const struct
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
*addr = DISP_REG_CONFIG_OUT_SEL;
value = BLS_TO_DPI_RDMA1_TO_DSI;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DPI0;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DPI1;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DSI1;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DSI2;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DSI3;
+ } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
+ value = RDMA1_SOUT_DSI1;
+ } else if (cur == DDP_COMPONENT_RDMA1 &&
[PATCH v5, 06/32] arm64: dts: add display nodes for mt8183
From: Yongqiang Niu
This patch add display nodes for mt8183
Signed-off-by: Yongqiang Niu
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 111 +++
1 file changed, 111 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 7cae10f..c07ee8c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -18,6 +18,14 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ ovl0 =
+ ovl_2l0 = _2l0;
+ ovl_2l1 = _2l1;
+ rdma0 =
+ rdma1 =
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -463,6 +471,109 @@
#clock-cells = <1>;
};
+ display_components: dispsys@1400 {
+ compatible = "mediatek,mt8183-display";
+ reg = <0 0x1400 0 0x1000>;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ };
+
+ ovl0: ovl@14008000 {
+ compatible = "mediatek,mt8183-disp-ovl";
+ reg = <0 0x14008000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_OVL0>;
+ mediatek,larb = <>;
+ };
+
+ ovl_2l0: ovl@14009000 {
+ compatible = "mediatek,mt8183-disp-ovl-2l";
+ reg = <0 0x14009000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_OVL0_2L>;
+ mediatek,larb = <>;
+ };
+
+ ovl_2l1: ovl@1400a000 {
+ compatible = "mediatek,mt8183-disp-ovl-2l";
+ reg = <0 0x1400a000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_OVL1_2L>;
+ mediatek,larb = <>;
+ };
+
+ rdma0: rdma@1400b000 {
+ compatible = "mediatek,mt8183-disp-rdma";
+ reg = <0 0x1400b000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_RDMA0>;
+ mediatek,larb = <>;
+ mediatek,rdma_fifo_size = <5>;
+ };
+
+ rdma1: rdma@1400c000 {
+ compatible = "mediatek,mt8183-disp-rdma1";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_RDMA1>;
+ mediatek,larb = <>;
+ mediatek,rdma_fifo_size = <2>;
+ };
+
+ color0: color@1400e000 {
+ compatible = "mediatek,mt8183-disp-color",
+"mediatek,mt8173-disp-color";
+ reg = <0 0x1400e000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_COLOR0>;
+ };
+
+ ccorr0: ccorr@1400f000 {
+ compatible = "mediatek,mt8183-disp-ccorr";
+ reg = <0 0x1400f000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_CCORR0>;
+ };
+
+ aal0: aal@1401 {
+ compatible = "mediatek,mt8183-disp-aal",
+"mediatek,mt8173-disp-aal";
+ reg = <0 0x1401 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_AAL0>;
+ };
+
+ gamma0: gamma@14011000 {
+ compatible = "mediatek,mt8183-disp-gamma",
+"mediatek,mt8173-disp-gamma";
+ reg = <0 0x14011000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_GAMMA0>;
+ };
+
+ dither0: dither@14012000 {
+ compatible = "mediatek,mt8183-disp-dither";
+ reg = <0 0x14012000 0 0x1000>;
+ interrupts = ;
+
[PATCH v4 12/14] drm/mxsfb: Clear OUTSTANDING_REQS bits
Bit 21 can alter the CTRL2_OUTSTANDING_REQS value right after the eLCDIF
is enabled, since it comes up with default value of 1 (this behaviour
has been seen on some imx8 platforms).
In order to fix this, clear CTRL2_OUTSTANDING_REQS bits before setting
its value.
Signed-off-by: Robert Chiras
Tested-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index e727f5e..a12f53d 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -225,6 +225,13 @@ static void mxsfb_enable_controller(struct
mxsfb_drm_private *mxsfb)
clk_prepare_enable(mxsfb->clk);
if (mxsfb->devdata->ipversion >= 4) {
+ /*
+* On some platforms, bit 21 is defaulted to 1, which may alter
+* the below setting. So, to make sure we have the right setting
+* clear all the bits for CTRL2_OUTSTANDING_REQS.
+*/
+ writel(CTRL2_OUTSTANDING_REQS(0x7),
+ mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
writel(CTRL2_OUTSTANDING_REQS(REQ_16),
mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
/* Assert LCD Reset bit */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 00/14] Improvements and fixes for mxsfb DRM driver
This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM and 8QXP). Following, are the new features added and fixes from this patch-set: 1. Add support for drm_bridge On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel display connector, where an LCD panel can be attached, but instead it is connected to DSI controller. Since this DSI stands between the display controller (eLCDIF) and the physical connector, the DSI can be implemented as a DRM bridge. So, in order to be able to connect the mxsfb driver to the DSI driver, the support for a drm_bridge was needed in mxsfb DRM driver (the actual driver for the eLCDIF block). 2. Add support for additional pixel formats Some of the pixel formats needed by Android were not implemented in this driver, but they were actually supported. So, add support for them. 3. Add support for horizontal stride Having support for horizontal stride allows the use of eLCDIF with a GPU (for example) that can only output resolution sizes multiple of a power of 8. For example, 1080 is not a power of 16, so in order to support 1920x1080 output from GPUs that can produce linear buffers only in sizes multiple to 16, this feature is needed. 3. Few minor features and bug-fixing The addition of max-memory-bandwidth DT property was actually needed in order to limit the bandwidth usage of the eLCDIF block. This is need on systems where multiple display controllers are presend and the memory bandwidth is not enough to handle all of them at maximum capacity (like it is the case on 8MQ, where there are two display controllers: DCSS and eLCDIF). The rest of the patches are bug-fixes. v4: - Removed the "Fix vblank events" patch (will cover this issue later, on a separate thread) - Colleted "Tested-by" from Guido - Collected "Reviewed-by" from Rob Herring v3: - Removed the max-res property patches and added support for max-memory-bandwidth property, as it is also implemented in other drivers - Removed unnecessary drm_vblank_off in probe v2: - Collected Tested-by from Guido - Split the first patch, which added more than one feature into relevant patches, explaining each feature added - Also split the second patch into more patches, to differentiate between the feature itself (additional pixel formats support) and the cleanup of the register definitions for a better representation (guido) - Included a patch submitted by Guido, while he was testing my patch-set Guido Günther (1): drm/mxsfb: Read bus flags from bridge if present Mirela Rabulea (1): drm/mxsfb: Signal mode changed when bpp changed Robert Chiras (12): drm/mxsfb: Update mxsfb to support a bridge drm/mxsfb: Add defines for the rest of registers drm/mxsfb: Reset vital registers for a proper initialization drm/mxsfb: Update register definitions using bit manipulation defines drm/mxsfb: Update mxsfb with additional pixel formats drm/mxsfb: Add max-memory-bandwidth property for MXSFB dt-bindings: display: Add max-memory-bandwidth property for mxsfb drm/mxsfb: Update mxsfb to support LCD reset drm/mxsfb: Improve the axi clock usage drm/mxsfb: Clear OUTSTANDING_REQS bits drm/mxsfb: Add support for horizontal stride drm/mxsfb: Add support for live pixel format change .../devicetree/bindings/display/mxsfb.txt | 5 + drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 287 ++--- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 194 -- drivers/gpu/drm/mxsfb/mxsfb_drv.h | 12 +- drivers/gpu/drm/mxsfb/mxsfb_out.c | 26 +- drivers/gpu/drm/mxsfb/mxsfb_regs.h | 193 +- 6 files changed, 581 insertions(+), 136 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4, 12/33] drm/mediatek: split DISP_REG_CONFIG_DSI_SEL setting into another use case
On Wed, 2019-07-17 at 13:35 +0800, CK Hu wrote:
> Hi, Yongqiang:
>
> On Tue, 2019-07-09 at 06:33 +0800, yongqiang@mediatek.com wrote:
> > From: Yongqiang Niu
> >
> > Here is two modifition in this patch:
> > 1.bls->dpi0 and rdma1->dsi are differen usecase,
> > Split DISP_REG_CONFIG_DSI_SEL setting into anther usecase
> > 2.remove DISP_REG_CONFIG_DPI_SEL setting, DPI_SEL_IN_BLS is 0 and
> > this is same with hardware defautl setting,
> >
>
> You move 2 register setting out of the path from BLS to DPI0, does this
> path still work? Please make sure that all modification could work on
> all supported SoC.
>
> Regards,
> CK
>
DPI_SEL_IN_BLS is 0 and this is same with hardware default setting as
description in patch.
the removed sentence is useless.
> > Signed-off-by: Yongqiang Niu
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index d015c1a..47b3e35 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -400,10 +400,9 @@ static void mtk_ddp_sout_sel(void __iomem *config_regs,
> > } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> > writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
> >config_regs + DISP_REG_CONFIG_OUT_SEL);
> > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
> > writel_relaxed(DSI_SEL_IN_RDMA,
> >config_regs + DISP_REG_CONFIG_DSI_SEL);
> > - writel_relaxed(DPI_SEL_IN_BLS,
> > - config_regs + DISP_REG_CONFIG_DPI_SEL);
> > }
> > }
> >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/14] drm/mxsfb: Update mxsfb to support LCD reset
The eLCDIF controller has control pin for the external LCD reset pin.
Add support for it and assert this pin in enable and de-assert it in
disable.
Signed-off-by: Robert Chiras
Tested-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 14 ++
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 2 ++
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 1be29f5..a4ba368 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -224,9 +224,12 @@ static void mxsfb_enable_controller(struct
mxsfb_drm_private *mxsfb)
clk_prepare_enable(mxsfb->clk_disp_axi);
clk_prepare_enable(mxsfb->clk);
- if (mxsfb->devdata->ipversion >= 4)
+ if (mxsfb->devdata->ipversion >= 4) {
writel(CTRL2_OUTSTANDING_REQS(REQ_16),
mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
+ /* Assert LCD Reset bit */
+ writel(CTRL2_LCD_RESET, mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
+ }
/* If it was disabled, re-enable the mode again */
writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
@@ -244,11 +247,14 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
{
u32 reg;
- if (mxsfb->devdata->ipversion >= 4)
+ writel(CTRL_RUN, mxsfb->base + LCDC_CTRL + REG_CLR);
+
+ if (mxsfb->devdata->ipversion >= 4) {
writel(CTRL2_OUTSTANDING_REQS(0x7),
mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
-
- writel(CTRL_RUN, mxsfb->base + LCDC_CTRL + REG_CLR);
+ /* De-assert LCD Reset bit */
+ writel(CTRL2_LCD_RESET, mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
+ }
/*
* Even if we disable the controller here, it will still continue
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_regs.h
b/drivers/gpu/drm/mxsfb/mxsfb_regs.h
index dc4daa0..0f63ba1 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_regs.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_regs.h
@@ -108,6 +108,8 @@
#define CTRL2_LINE_PATTERN_BGR 5
#define CTRL2_LINE_PATTERN_CLR 7
+#define CTRL2_LCD_RESETBIT(0)
+
#define TRANSFER_COUNT_SET_VCOUNT(x) REG_PUT((x), 31, 16)
#define TRANSFER_COUNT_GET_VCOUNT(x) REG_GET((x), 31, 16)
#define TRANSFER_COUNT_SET_HCOUNT(x) REG_PUT((x), 15, 0)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v12 0/6] drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+
>-Original Message- >From: dri-devel On Behalf Of >Ramalingam >C >Sent: Wednesday, August 28, 2019 10:12 PM >To: intel-gfx ; dri-devel de...@lists.freedesktop.org> >Cc: Nikula, Jani ; Winkler, Tomas > >Subject: [PATCH v12 0/6] drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+ > >Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement from >DDI into transcoder. > >v12: > r-b and ack are collected. > few review comments are addressed. With the Acks from Tomas and Jani N, and RB from Shashank. Pushed the series to dinq. Thanks for the patches and the reviews. Regards, Uma Shankar >Ramalingam C (6): > drm/i915: mei_hdcp: I915 sends ddi index as per ME FW > drm: Move port definition back to i915 header > drm: Extend I915 mei interface for transcoder info > misc/mei/hdcp: Fill transcoder index in port info > drm/i915/hdcp: update current transcoder into intel_hdcp > drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+ > > drivers/gpu/drm/i915/display/intel_bios.h | 3 +- > drivers/gpu/drm/i915/display/intel_display.h | 20 +- > .../drm/i915/display/intel_display_types.h| 7 + > drivers/gpu/drm/i915/display/intel_dp.c | 3 + > drivers/gpu/drm/i915/display/intel_dp.h | 1 + > drivers/gpu/drm/i915/display/intel_hdcp.c | 214 +- > drivers/gpu/drm/i915/display/intel_hdcp.h | 4 + > drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +- > drivers/gpu/drm/i915/display/intel_hdmi.h | 1 + > drivers/gpu/drm/i915/display/intel_hotplug.h | 1 + > drivers/gpu/drm/i915/display/intel_sdvo.h | 1 + > drivers/gpu/drm/i915/i915_reg.h | 124 +- > drivers/misc/mei/hdcp/mei_hdcp.c | 45 ++-- > drivers/misc/mei/hdcp/mei_hdcp.h | 17 +- > include/drm/i915_drm.h| 18 -- > include/drm/i915_mei_hdcp_interface.h | 42 +++- > 16 files changed, 389 insertions(+), 125 deletions(-) > >-- >2.20.1 > >___ >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 2/2] drm/mediatek: Apply CMDQ control flow
Hi, Bibby:
On Fri, 2019-08-30 at 15:41 +0800, Bibby Hsieh wrote:
> Unlike other SoCs, MT8183 does not have "shadow"
> registers for performaing an atomic video mode
> set or page flip at vblank/vsync.
>
> The CMDQ (Commend Queue) in MT8183 is used to help
> update all relevant display controller registers
> with critical time limation.
>
> Signed-off-by: YT Shen
> Signed-off-by: CK Hu
> Signed-off-by: Philipp Zabel
> Signed-off-by: Bibby Hsieh
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 190 +---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 34
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 +
> drivers/gpu/drm/mediatek/mtk_drm_plane.c| 4 +
> 5 files changed, 206 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 092e502ed27b..329ca5a14c39 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -10,7 +10,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
>
> #include "mtk_drm_drv.h"
> #include "mtk_drm_crtc.h"
> @@ -41,6 +43,10 @@ struct mtk_drm_crtc {
> unsigned intlayer_nr;
> boolpending_planes;
> boolcursor_update;
> +
> + struct cmdq_client *cmdq_client;
> + u32 cmdq_event;
> +
> void __iomem*config_regs;
> const struct mtk_mmsys_reg_data *mmsys_reg_data;
> struct mtk_disp_mutex *mutex;
> @@ -57,6 +63,12 @@ struct mtk_crtc_state {
> unsigned intpending_width;
> unsigned intpending_height;
> unsigned intpending_vrefresh;
> + struct cmdq_pkt *cmdq_handle;
> +};
> +
> +struct mtk_cmdq_cb_data {
> + struct drm_crtc_state *state;
> + struct cmdq_pkt *cmdq_handle;
> };
>
> static inline struct mtk_drm_crtc *to_mtk_crtc(struct drm_crtc *c)
> @@ -208,6 +220,46 @@ static void mtk_crtc_ddp_clk_disable(struct mtk_drm_crtc
> *mtk_crtc)
> clk_disable_unprepare(mtk_crtc->ddp_comp[i]->clk);
> }
>
> +static void ddp_cmdq_cursor_cb(struct cmdq_cb_data data)
> +{
> +
> +#if IS_ENABLED(CONFIG_MTK_CMDQ)
I would like the whole ddp_cmdq_cursor_cb() and ddp_cmdq_cb() inside
this part.
> + struct mtk_cmdq_cb_data *cb_data = data.data;
> +
> + DRM_DEBUG_DRIVER("%s\n", __func__);
> +
> + cmdq_pkt_destroy(cb_data->cmdq_handle);
> + kfree(cb_data);
> +#endif
> +
> +}
> +
> +static void ddp_cmdq_cb(struct cmdq_cb_data data)
> +{
> +
> +#if IS_ENABLED(CONFIG_MTK_CMDQ)
> + struct mtk_cmdq_cb_data *cb_data = data.data;
> + struct drm_crtc_state *crtc_state = cb_data->state;
> + struct drm_atomic_state *atomic_state = crtc_state->state;
> + struct drm_crtc *crtc = crtc_state->crtc;
> + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> +
> + DRM_DEBUG_DRIVER("%s\n", __func__);
> +
> + if (mtk_crtc->pending_needs_vblank) {
> + /* cmdq_vblank_event must be read after cmdq_needs_event */
> + smp_rmb();
> +
> + mtk_drm_crtc_finish_page_flip(mtk_crtc);
> + mtk_crtc->pending_needs_vblank = false;
> + }
> + mtk_atomic_state_put_queue(atomic_state);
> + cmdq_pkt_destroy(cb_data->cmdq_handle);
> + kfree(cb_data);
> +#endif
> +
> +}
> +
> static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
> {
> struct drm_crtc *crtc = _crtc->base;
> @@ -283,7 +335,8 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> *mtk_crtc)
> if (prev == DDP_COMPONENT_OVL0)
> mtk_ddp_comp_bgclr_in_on(comp);
>
> - mtk_ddp_comp_config(comp, width, height, vrefresh, bpc);
> + mtk_ddp_comp_config(comp, width, height,
> + vrefresh, bpc, NULL);
> mtk_ddp_comp_start(comp);
> }
>
> @@ -303,7 +356,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> *mtk_crtc)
> } else
> local_layer = i;
> mtk_ddp_comp_layer_config(comp, local_layer,
> - plane_state);
> + plane_state, NULL);
> }
>
> return 0;
> @@ -361,7 +414,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> if (state->pending_config) {
> mtk_ddp_comp_config(comp, state->pending_width,
> state->pending_height,
> - state->pending_vrefresh, 0);
> + state->pending_vrefresh, 0, NULL);
>
> state->pending_config = false;
> }
> @@ -381,7
[PATCH 0/2] Support CMDQ interface and control flow
The CMDQ (Command Queue) in MT8183 is used to help update all relevant display controller registers with critical time limation. These patched add CMDQ interface in ddp_comp interface and add CMDQ control flow. This patch depends on ptach: drm/mediatek: fixup cursor moving unsmooth issue (https://patchwork.kernel.org/cover/11123119/) add drm support for MT8183 (https://patchwork.kernel.org/cover/11121519/) support gce on mt8183 platform (https://patchwork.kernel.org/cover/11120153/) Bibby Hsieh (2): drm/mediatek: Support CMDQ interface in ddp component drm/mediatek: Apply CMDQ control flow drivers/gpu/drm/mediatek/mtk_disp_color.c | 7 +- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 78 drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 66 +++ drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 190 +--- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 144 +++ drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 55 -- drivers/gpu/drm/mediatek/mtk_drm_plane.c| 4 + 8 files changed, 393 insertions(+), 153 deletions(-) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/mediatek: Apply CMDQ control flow
Unlike other SoCs, MT8183 does not have "shadow"
registers for performaing an atomic video mode
set or page flip at vblank/vsync.
The CMDQ (Commend Queue) in MT8183 is used to help
update all relevant display controller registers
with critical time limation.
Signed-off-by: YT Shen
Signed-off-by: CK Hu
Signed-off-by: Philipp Zabel
Signed-off-by: Bibby Hsieh
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 190 +---
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 34
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 +
drivers/gpu/drm/mediatek/mtk_drm_plane.c| 4 +
5 files changed, 206 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 092e502ed27b..329ca5a14c39 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -10,7 +10,9 @@
#include
#include
#include
+#include
#include
+#include
#include "mtk_drm_drv.h"
#include "mtk_drm_crtc.h"
@@ -41,6 +43,10 @@ struct mtk_drm_crtc {
unsigned intlayer_nr;
boolpending_planes;
boolcursor_update;
+
+ struct cmdq_client *cmdq_client;
+ u32 cmdq_event;
+
void __iomem*config_regs;
const struct mtk_mmsys_reg_data *mmsys_reg_data;
struct mtk_disp_mutex *mutex;
@@ -57,6 +63,12 @@ struct mtk_crtc_state {
unsigned intpending_width;
unsigned intpending_height;
unsigned intpending_vrefresh;
+ struct cmdq_pkt *cmdq_handle;
+};
+
+struct mtk_cmdq_cb_data {
+ struct drm_crtc_state *state;
+ struct cmdq_pkt *cmdq_handle;
};
static inline struct mtk_drm_crtc *to_mtk_crtc(struct drm_crtc *c)
@@ -208,6 +220,46 @@ static void mtk_crtc_ddp_clk_disable(struct mtk_drm_crtc
*mtk_crtc)
clk_disable_unprepare(mtk_crtc->ddp_comp[i]->clk);
}
+static void ddp_cmdq_cursor_cb(struct cmdq_cb_data data)
+{
+
+#if IS_ENABLED(CONFIG_MTK_CMDQ)
+ struct mtk_cmdq_cb_data *cb_data = data.data;
+
+ DRM_DEBUG_DRIVER("%s\n", __func__);
+
+ cmdq_pkt_destroy(cb_data->cmdq_handle);
+ kfree(cb_data);
+#endif
+
+}
+
+static void ddp_cmdq_cb(struct cmdq_cb_data data)
+{
+
+#if IS_ENABLED(CONFIG_MTK_CMDQ)
+ struct mtk_cmdq_cb_data *cb_data = data.data;
+ struct drm_crtc_state *crtc_state = cb_data->state;
+ struct drm_atomic_state *atomic_state = crtc_state->state;
+ struct drm_crtc *crtc = crtc_state->crtc;
+ struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+
+ DRM_DEBUG_DRIVER("%s\n", __func__);
+
+ if (mtk_crtc->pending_needs_vblank) {
+ /* cmdq_vblank_event must be read after cmdq_needs_event */
+ smp_rmb();
+
+ mtk_drm_crtc_finish_page_flip(mtk_crtc);
+ mtk_crtc->pending_needs_vblank = false;
+ }
+ mtk_atomic_state_put_queue(atomic_state);
+ cmdq_pkt_destroy(cb_data->cmdq_handle);
+ kfree(cb_data);
+#endif
+
+}
+
static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
{
struct drm_crtc *crtc = _crtc->base;
@@ -283,7 +335,8 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
if (prev == DDP_COMPONENT_OVL0)
mtk_ddp_comp_bgclr_in_on(comp);
- mtk_ddp_comp_config(comp, width, height, vrefresh, bpc);
+ mtk_ddp_comp_config(comp, width, height,
+ vrefresh, bpc, NULL);
mtk_ddp_comp_start(comp);
}
@@ -303,7 +356,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
} else
local_layer = i;
mtk_ddp_comp_layer_config(comp, local_layer,
- plane_state);
+ plane_state, NULL);
}
return 0;
@@ -361,7 +414,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
if (state->pending_config) {
mtk_ddp_comp_config(comp, state->pending_width,
state->pending_height,
- state->pending_vrefresh, 0);
+ state->pending_vrefresh, 0, NULL);
state->pending_config = false;
}
@@ -381,7 +434,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
local_layer = i;
mtk_ddp_comp_layer_config(comp, local_layer,
- plane_state);
+
[PATCH 1/2] drm/mediatek: Support CMDQ interface in ddp component
The CMDQ (Command Queue) in MT8183 is used to help
update all relevant display controller registers
with critical time limation.
This patch add cmdq interface in ddp_comp interface,
let all ddp_comp interface can support cpu/cmdq function
at the same time.
Signed-off-by: YT Shen
Signed-off-by: CK Hu
Signed-off-by: Philipp Zabel
Signed-off-by: Bibby Hsieh
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_disp_color.c | 7 +-
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 78 +++---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 66 ++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 110 ++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 53 ++
5 files changed, 187 insertions(+), 127 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index f33d98b356d6..c5d3e3cf8ad5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "mtk_drm_crtc.h"
#include "mtk_drm_ddp_comp.h"
@@ -45,12 +46,12 @@ static inline struct mtk_disp_color *comp_to_color(struct
mtk_ddp_comp *comp)
static void mtk_color_config(struct mtk_ddp_comp *comp, unsigned int w,
unsigned int h, unsigned int vrefresh,
-unsigned int bpc)
+unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
struct mtk_disp_color *color = comp_to_color(comp);
- writel(w, comp->regs + DISP_COLOR_WIDTH(color));
- writel(h, comp->regs + DISP_COLOR_HEIGHT(color));
+ mtk_ddp_write(cmdq_pkt, w, comp, DISP_COLOR_WIDTH(color));
+ mtk_ddp_write(cmdq_pkt, h, comp, DISP_COLOR_HEIGHT(color));
}
static void mtk_color_start(struct mtk_ddp_comp *comp)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 94c80c215c6e..f11c785199d3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "mtk_drm_crtc.h"
#include "mtk_drm_ddp_comp.h"
@@ -120,14 +121,15 @@ static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
static void mtk_ovl_config(struct mtk_ddp_comp *comp, unsigned int w,
unsigned int h, unsigned int vrefresh,
- unsigned int bpc)
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
if (w != 0 && h != 0)
- writel_relaxed(h << 16 | w, comp->regs + DISP_REG_OVL_ROI_SIZE);
- writel_relaxed(0x0, comp->regs + DISP_REG_OVL_ROI_BGCLR);
+ mtk_ddp_write_relaxed(cmdq_pkt, h << 16 | w, comp,
+ DISP_REG_OVL_ROI_SIZE);
+ mtk_ddp_write_relaxed(cmdq_pkt, 0x0, comp, DISP_REG_OVL_ROI_BGCLR);
- writel(0x1, comp->regs + DISP_REG_OVL_RST);
- writel(0x0, comp->regs + DISP_REG_OVL_RST);
+ mtk_ddp_write(cmdq_pkt, 0x1, comp, DISP_REG_OVL_RST);
+ mtk_ddp_write(cmdq_pkt, 0x0, comp, DISP_REG_OVL_RST);
}
static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp *comp)
@@ -137,7 +139,8 @@ static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp
*comp)
return ovl->data->layer_nr;
}
-static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx)
+static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx,
+struct cmdq_pkt *cmdq_pkt)
{
unsigned int reg;
unsigned int gmc_thrshd_l;
@@ -145,8 +148,8 @@ static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp,
unsigned int idx)
unsigned int gmc_value;
struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
- writel(0x1, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
-
+ mtk_ddp_write(cmdq_pkt, 0x1, comp,
+ DISP_REG_OVL_RDMA_CTRL(idx));
gmc_thrshd_l = GMC_THRESHOLD_LOW >>
(GMC_THRESHOLD_BITS - ovl->data->gmc_bits);
gmc_thrshd_h = GMC_THRESHOLD_HIGH >>
@@ -156,22 +159,19 @@ static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp,
unsigned int idx)
else
gmc_value = gmc_thrshd_l | gmc_thrshd_l << 8 |
gmc_thrshd_h << 16 | gmc_thrshd_h << 24;
- writel(gmc_value, comp->regs + DISP_REG_OVL_RDMA_GMC(idx));
-
- reg = readl(comp->regs + DISP_REG_OVL_SRC_CON);
- reg = reg | BIT(idx);
- writel(reg, comp->regs + DISP_REG_OVL_SRC_CON);
+ mtk_ddp_write(cmdq_pkt, gmc_value,
+ comp, DISP_REG_OVL_RDMA_GMC(idx));
+ mtk_ddp_write_mask(cmdq_pkt, BIT(idx), comp,
+ DISP_REG_OVL_SRC_CON, BIT(idx));
}
-static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp, unsigned int idx)
+static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp, unsigned int idx,
+ struct cmdq_pkt *cmdq_pkt)
{
-
[PATCH 1/2] drm/mediatek: Only block updates to CRTCs that have a pending update
Currently we use a single mutex to allow only a single atomic
update at a time. In truth, though, we really only want to
ensure that only a single atomic update is allowed per CRTC.
In other words, for each atomic update, we only block if there
is a pending update for the CRTCs involved, and don't block if
there are only pending updates for other CRTCs.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Daniel Kurtz
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 14 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 182 +---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 12 +-
3 files changed, 184 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index b55970a2869d..7697b40baac0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -45,6 +46,8 @@ struct mtk_drm_crtc {
struct mtk_disp_mutex *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
+
+ struct drm_crtc_state *old_crtc_state;
};
struct mtk_crtc_state {
@@ -343,6 +346,7 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ struct drm_atomic_state *atomic_state = mtk_crtc->old_crtc_state->state;
struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
unsigned int i;
@@ -382,6 +386,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
}
}
mtk_crtc->pending_planes = false;
+ mtk_atomic_state_put_queue(atomic_state);
}
}
@@ -451,6 +456,7 @@ static void mtk_drm_crtc_atomic_begin(struct drm_crtc *crtc,
static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
{
+ struct drm_atomic_state *old_atomic_state = old_crtc_state->state;
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
struct mtk_drm_private *priv = crtc->dev->dev_private;
unsigned int pending_planes = 0;
@@ -469,8 +475,13 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
pending_planes |= BIT(i);
}
}
- if (pending_planes)
+
+ if (pending_planes) {
mtk_crtc->pending_planes = true;
+ drm_atomic_state_get(old_atomic_state);
+ mtk_crtc->old_crtc_state = old_crtc_state;
+ }
+
if (crtc->state->color_mgmt_changed)
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
@@ -526,6 +537,7 @@ static int mtk_drm_crtc_init(struct drm_device *drm,
void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *comp)
{
+
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
struct mtk_drm_private *priv = crtc->dev->dev_private;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index c0928b69dc43..b0308a3a7483 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -31,11 +31,120 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static void mtk_atomic_schedule(struct mtk_drm_private *private,
+struct mtk_atomic_state {
+ struct drm_atomic_state base;
+ struct list_head list;
+ struct work_struct work;
+};
+
+static inline struct mtk_atomic_state *to_mtk_state(struct drm_atomic_state *s)
+{
+ return container_of(s, struct mtk_atomic_state, base);
+}
+
+void mtk_atomic_state_put_queue(struct drm_atomic_state *state)
+{
+ struct drm_device *drm = state->dev;
+ struct mtk_drm_private *mtk_drm = drm->dev_private;
+ struct mtk_atomic_state *mtk_state = to_mtk_state(state);
+ unsigned long flags;
+
+ spin_lock_irqsave(_drm->unreference.lock, flags);
+ list_add_tail(_state->list, _drm->unreference.list);
+ spin_unlock_irqrestore(_drm->unreference.lock, flags);
+
+ schedule_work(_drm->unreference.work);
+}
+
+static uint32_t mtk_atomic_crtc_mask(struct drm_device *drm,
+struct drm_atomic_state *state)
+{
+ uint32_t crtc_mask;
+ int i;
+
+ for (i = 0, crtc_mask = 0; i < drm->mode_config.num_crtc; i++) {
+ struct drm_crtc *crtc = state->crtcs[i].ptr;
+
+ if (crtc)
+ crtc_mask |= (1 << drm_crtc_index(crtc));
+ }
+
+ return crtc_mask;
+}
+
+/*
+ * Block until specified crtcs are no longer pending update,
[PATCH 2/2] drm/mediatek: Bypass atomic helpers for cursor updates
Moving the driver to atomic helpers regressed cursor responsiveness,
because cursor updates need their own atomic commits, which have to be
serialized with other commits, that might include fence waits. To avoid
this, in certain conditions, we can bypass the atomic helpers for legacy
cursor update IOCTLs. Currently the conditions are:
- no asynchronous mode setting commit pending,
- no asynchronous commit that updates the cursor plane is pending.
With the above two conditions met, we know that the manual cursor state
update will not conflict with any scheduled update.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Bibby Hsieh
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 41 -
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 34 ++-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 +
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 73 +++-
5 files changed, 148 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 7697b40baac0..092e502ed27b 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -40,7 +40,7 @@ struct mtk_drm_crtc {
struct drm_plane*planes;
unsigned intlayer_nr;
boolpending_planes;
-
+ boolcursor_update;
void __iomem*config_regs;
const struct mtk_mmsys_reg_data *mmsys_reg_data;
struct mtk_disp_mutex *mutex;
@@ -386,8 +386,45 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
}
}
mtk_crtc->pending_planes = false;
- mtk_atomic_state_put_queue(atomic_state);
+ if (!mtk_crtc->cursor_update)
+ mtk_atomic_state_put_queue(atomic_state);
+ mtk_crtc->cursor_update = false;
+ }
+}
+
+void mtk_drm_crtc_cursor_update(struct drm_crtc *crtc, struct drm_plane *plane,
+ struct drm_plane_state *plane_state)
+{
+ struct mtk_drm_private *priv = crtc->dev->dev_private;
+ struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ const struct drm_plane_helper_funcs *plane_helper_funcs =
+ plane->helper_private;
+ int i;
+
+ if (!mtk_crtc->enabled)
+ return;
+
+ mutex_lock(>hw_lock);
+ plane_helper_funcs->atomic_update(plane, plane_state);
+ for (i = 0; i < mtk_crtc->layer_nr; i++) {
+ struct drm_plane *plane = _crtc->planes[i];
+ struct mtk_plane_state *plane_state;
+
+ plane_state = to_mtk_plane_state(plane->state);
+ if (plane_state->pending.dirty) {
+ plane_state->pending.config = true;
+ plane_state->pending.dirty = false;
+ }
+ }
+ mtk_crtc->pending_planes = true;
+ mtk_crtc->cursor_update = true;
+
+ if (priv->data->shadow_register) {
+ mtk_disp_mutex_acquire(mtk_crtc->mutex);
+ mtk_crtc_ddp_config(crtc);
+ mtk_disp_mutex_release(mtk_crtc->mutex);
}
+ mutex_unlock(>hw_lock);
}
static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index fcc134eb00c9..46e903be68ec 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
@@ -19,5 +19,7 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct
mtk_ddp_comp *comp);
int mtk_drm_crtc_create(struct drm_device *drm_dev,
const enum mtk_ddp_comp_id *path,
unsigned int path_len);
+void mtk_drm_crtc_cursor_update(struct drm_crtc *crtc, struct drm_plane *plane,
+ struct drm_plane_state *plane_state);
#endif /* MTK_DRM_CRTC_H */
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index b0308a3a7483..ca754b954c7c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -80,11 +80,36 @@ static int mtk_atomic_get_crtcs(struct drm_device *drm,
struct drm_atomic_state *state)
{
struct mtk_drm_private *private = drm->dev_private;
- uint32_t crtc_mask;
+ uint32_t crtc_mask, needs_modeset, has_cursor_plane;
+ struct drm_plane *plane;
+ struct drm_plane_state *plane_state;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ int i;
int ret;
crtc_mask = mtk_atomic_crtc_mask(drm, state);
+ /*
+* Allow cursor updates unless there is a pending modeset or cursor
+*
[PATCH 0/2] drm/mediatek: fixup cursor moving unsmooth issue
These patches can fixup cursor moving is not smooth when heavy load in webgl. Bibby Hsieh (2): drm/mediatek: Only block updates to CRTCs that have a pending update drm/mediatek: Bypass atomic helpers for cursor updates drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 53 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 214 --- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 15 +- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 73 +++- 5 files changed, 330 insertions(+), 27 deletions(-) -- 2.18.0
Re: [RFC][PATCH] drm: kirin: Fix dsi probe/attach logic
On 29.08.2019 19:39, Rob Clark wrote:
> On Wed, Aug 28, 2019 at 11:06 PM John Stultz wrote:
>> Since commit 83f35bc3a852 ("drm/bridge: adv7511: Attach to DSI
>> host at probe time") landed in -next the HiKey board would fail
>> to boot, looping:
> No, please revert 83f35bc3a852.. that is going in the *complete* wrong
> direction. We actually should be moving panels to not require dsi
> host until attach time, similar to how bridges work, not the other way
> around.
Devices of panels and bridges controlled via DSI will not appear at all
if DSI host is not created.
So this is the only direction!!!
>
> The problem is that, when dealing with bootloader enabled display, we
> need to be really careful not to touch the hardware until the display
> driver knows the bridge/panel is present. If the bridge/panel probes
> after the display driver, we could end up killing scanout
> (efifb/simplefb).. if the bridge/panel is missing some dependency and
> never probes, it is rather unpleasant to be stuck trying to debug what
> went wrong with no display.
It has nothing to do with touching hardware, you can always (I hope)
postpone it till all components are present.
But it is just requirement of device/driver model in Linux Kernel.
>
> Sorry I didn't notice that adv7511 patch before it landed, but the
> right thing to do now is to revert it.
The 1st version of the patch was posted at the end of April and final
version was queued 1st July, so it was quite long time for discussions
and tests.
Reverting it now seems quite late, especially if the patch does right
thing and there is already proper fix for one encoder (kirin), moreover
revert will break another platforms.
Of course it seems you have different opinion what is the right thing in
this case, so if you convince us that your approach is better one can
revert the patch.
Regards
Andrzej
>
> BR,
> -R
>
>> adv7511 2-0039: failed to find dsi host
>>
>> messages over and over. Andrzej Hajda suggested this is due to a
>> circular dependency issue, and that the adv7511 change is
>> correcting the improper order used earlier.
>>
>> Unfortunately this means the DSI drivers that use adv7511 need
>> to also need to be updated to use the proper ordering to
>> continue to work.
>>
>> This patch tries to reorder the initialization to register the
>> dsi_host first, and then call component_add via dsi_host_attach,
>> instead of doing that at probe time.
>>
>> This seems to resolve the issue with the HiKey board.
>>
>> Cc: Andrzej Hajda
>> Cc: Matt Redfearn
>> Cc: Xinliang Liu
>> Cc: Rongrong Zou
>> Cc: Laurent Pinchart
>> Cc: Neil Armstrong
>> Cc: Jonas Karlman
>> Cc: Jernej Skrabec
>> Cc: Thierry Reding
>> Cc: David Airlie ,
>> Cc: Sean Paul
>> Cc: Sam Ravnborg
>> Cc: "dri-devel@lists.freedesktop.org"
>> Fixes: 83f35bc3a852 ("drm/bridge: adv7511: Attach to DSI host at probe time")
>> Signed-off-by: John Stultz
>> ---
>> Note: I'm really not super familiar with the DSI code here,
>> and am mostly just trying to refactor the existing code in a
>> similar fashion to the suggested dw-mipi-dsi-rockchip.c
>> implementation. Careful review would be greatly appreciated!
>>
>> Also there is an outstanding regression on the db410c since it
>> similarly uses the adv7511 and probably needs a similar rework.
>> ---
>> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 111 ++-
>> 1 file changed, 56 insertions(+), 55 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
>> b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
>> index 5bf8138941de..696cee1a1219 100644
>> --- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
>> +++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
>> @@ -79,6 +79,7 @@ struct dsi_hw_ctx {
>> };
>>
>> struct dw_dsi {
>> + struct device *dev;
>> struct drm_encoder encoder;
>> struct drm_bridge *bridge;
>> struct mipi_dsi_host host;
>> @@ -724,51 +725,6 @@ static int dw_drm_encoder_init(struct device *dev,
>> return 0;
>> }
>>
>> -static int dsi_host_attach(struct mipi_dsi_host *host,
>> - struct mipi_dsi_device *mdsi)
>> -{
>> - struct dw_dsi *dsi = host_to_dsi(host);
>> -
>> - if (mdsi->lanes < 1 || mdsi->lanes > 4) {
>> - DRM_ERROR("dsi device params invalid\n");
>> - return -EINVAL;
>> - }
>> -
>> - dsi->lanes = mdsi->lanes;
>> - dsi->format = mdsi->format;
>> - dsi->mode_flags = mdsi->mode_flags;
>> -
>> - return 0;
>> -}
>> -
>> -static int dsi_host_detach(struct mipi_dsi_host *host,
>> - struct mipi_dsi_device *mdsi)
>> -{
>> - /* do nothing */
>> - return 0;
>> -}
>> -
>> -static const struct mipi_dsi_host_ops dsi_host_ops = {
>> - .attach = dsi_host_attach,
>> - .detach = dsi_host_detach,
>> -};
>> -
>> -static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
>> -{
>> - struct mipi_dsi_host *host =
Re: [PATCH v5, 32/32] drm/mediatek: add support for mediatek SOC MT8183
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add support for mediatek SOC MT8183
> 1.ovl_2l share driver with ovl
> 2.rdma1 share drive with rdma0, but fifo size is different
> 3.add mt8183 mutex private data, and mmsys private data
> 4.add mt8183 main and external path module for crtc create
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 27 -
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 69
>
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 ++
> 5 files changed, 161 insertions(+), 1 deletion(-)
>
[snip]
> @@ -613,6 +658,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops,
> mtk_drm_sys_suspend,
> .data = _mmsys_driver_data},
> { .compatible = "mediatek,mt8173-mmsys",
> .data = _mmsys_driver_data},
> + { .compatible = "mediatek,mt8183-display",
This should be "mediatek,mt8183-mmsys".
Regards,
CK
> + .data = _mmsys_driver_data},
> { }
> };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: Use vmalloc for command buffer allocations.
On Thu, Aug 29, 2019 at 11:09 PM Gerd Hoffmann wrote:
> Hi,
>
> > {
> > if (vbuf->resp_size > MAX_INLINE_RESP_SIZE)
> > kfree(vbuf->resp_buf);
> > - kfree(vbuf->data_buf);
> > + kvfree(vbuf->data_buf);
>
> if (is_vmalloc_addr(vbuf->data_buf)) ...
>
> needed here I gues?
>
kvfree() handles vmalloc/kmalloc/kvmalloc internally by doing that check.
>
> > +/* Create sg_table from a vmalloc'd buffer. */
> > +static struct sg_table *vmalloc_to_sgt(char *data, uint32_t size)
>
> Hmm, isn't there an existing function for that?
> I'd be surprised if virtio-gpu is the first driver needing this ...
>
> And it case there really isn't one this should probably added to the
> vmalloc or scatterlist code, not the virtio-gpu driver.
>
There's a few other similar ones around:
- pack_sg_list in net/9p/trans_virtio.c, assumes contiguous array of
scatterlist and non-vmalloc
- videobuf_vmalloc_to_sg in drivers/media/v4l2-core/videobuf-dma-sg.c,
assumes contiguous array of scatterlist and that the buffer being converted
is page aligned (the l
- vmalloc_to_sg() in drivers/media/common/saa7146/saa7146_core.c, duplicate
of videobuf_vmalloc_to_sg
None of the existing ones seemed to do what was needed and the convention
seemed to pack an sg table as needed for the usage and just keep it in the
module so that's what I followed. I'm not very familiar with these APIs so
maybe there's something I missed, but I did look through the helpers in
lib/scatterlist.c and didn't see anything. If you think it is better
suited to live in scatterlist I can prepare another change for that.
Dave
>
> cheers,
> Gerd
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5, 31/32] drm/mediatek: add connection from RDMA0 to DSI0
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add connection from RDMA0 to DSI0
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index fd38658..6a7cb15 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -42,6 +42,7 @@
> #define OVL1_2L_MOUT_EN_RDMA1BIT(4)
> #define DITHER0_MOUT_IN_DSI0 BIT(0)
> #define DISP_PATH0_SEL_IN_OVL0_2L0x1
> +#define DSI0_SEL_IN_RDMA00x1
>
> #define MT2701_DISP_MUTEX0_MOD0 0x2c
> #define MT2701_DISP_MUTEX0_SOF0 0x30
> @@ -391,6 +392,9 @@ static unsigned int mtk_ddp_sel_in(const struct
> mtk_mmsys_reg_data *data,
> next == DDP_COMPONENT_RDMA0) {
> *addr = MT8183_DISP_PATH0_SEL_IN;
> value = DISP_PATH0_SEL_IN_OVL0_2L;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI0) {
> + *addr = data->dsi0_sel_in;
> + value = DSI0_SEL_IN_RDMA0;
> } else {
> value = 0;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5, 30/32] drm/mediatek: add connection from DITHER0 to DSI0
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add connection from DITHER0 to DSI0
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 237824f..fd38658 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -35,10 +35,12 @@
>
> #define MT8183_DISP_OVL0_2L_MOUT_EN 0xf04
> #define MT8183_DISP_OVL1_2L_MOUT_EN 0xf08
> +#define MT8183_DISP_DITHER0_MOUT_EN 0xf0c
> #define MT8183_DISP_PATH0_SEL_IN 0xf24
>
> #define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
> #define OVL1_2L_MOUT_EN_RDMA1BIT(4)
> +#define DITHER0_MOUT_IN_DSI0 BIT(0)
> #define DISP_PATH0_SEL_IN_OVL0_2L0x1
>
> #define MT2701_DISP_MUTEX0_MOD0 0x2c
> @@ -323,6 +325,9 @@ static unsigned int mtk_ddp_mout_en(const struct
> mtk_mmsys_reg_data *data,
> next == DDP_COMPONENT_RDMA1) {
> *addr = MT8183_DISP_OVL1_2L_MOUT_EN;
> value = OVL1_2L_MOUT_EN_RDMA1;
> + } else if (cur == DDP_COMPONENT_DITHER && next == DDP_COMPONENT_DSI0) {
> + *addr = MT8183_DISP_DITHER0_MOUT_EN;
> + value = DITHER0_MOUT_IN_DSI0;
> } else {
> value = 0;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5, 29/32] drm/mediatek: add connection from OVL_2L1 to RDMA1
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add connection from OVL_2L1 to RDMA1
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 943e114..237824f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -34,9 +34,11 @@
> #define DISP_REG_CONFIG_DPI_SEL 0x064
>
> #define MT8183_DISP_OVL0_2L_MOUT_EN 0xf04
> +#define MT8183_DISP_OVL1_2L_MOUT_EN 0xf08
> #define MT8183_DISP_PATH0_SEL_IN 0xf24
>
> #define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
> +#define OVL1_2L_MOUT_EN_RDMA1BIT(4)
> #define DISP_PATH0_SEL_IN_OVL0_2L0x1
>
> #define MT2701_DISP_MUTEX0_MOD0 0x2c
> @@ -317,6 +319,10 @@ static unsigned int mtk_ddp_mout_en(const struct
> mtk_mmsys_reg_data *data,
> next == DDP_COMPONENT_RDMA0) {
> *addr = MT8183_DISP_OVL0_2L_MOUT_EN;
> value = OVL0_2L_MOUT_EN_DISP_PATH0;
> + } else if (cur == DDP_COMPONENT_OVL_2L1 &&
> +next == DDP_COMPONENT_RDMA1) {
> + *addr = MT8183_DISP_OVL1_2L_MOUT_EN;
> + value = OVL1_2L_MOUT_EN_RDMA1;
> } else {
> value = 0;
> }
Re: [PATCH v5, 28/32] drm/mediatek: add connection from OVL_2L0 to RDMA0
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> this patch add add connection from OVL_2L0 to RDMA0
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index aa6173b..943e114 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -33,6 +33,12 @@
> #define DISP_REG_CONFIG_DSI_SEL 0x050
> #define DISP_REG_CONFIG_DPI_SEL 0x064
>
> +#define MT8183_DISP_OVL0_2L_MOUT_EN 0xf04
> +#define MT8183_DISP_PATH0_SEL_IN 0xf24
> +
> +#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
> +#define DISP_PATH0_SEL_IN_OVL0_2L0x1
> +
> #define MT2701_DISP_MUTEX0_MOD0 0x2c
> #define MT2701_DISP_MUTEX0_SOF0 0x30
>
> @@ -307,6 +313,10 @@ static unsigned int mtk_ddp_mout_en(const struct
> mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0) {
> *addr = data->ovl0_mout_en;
> value = OVL0_MOUT_EN_OVL0_2L;
> + } else if (cur == DDP_COMPONENT_OVL_2L0 &&
> +next == DDP_COMPONENT_RDMA0) {
> + *addr = MT8183_DISP_OVL0_2L_MOUT_EN;
> + value = OVL0_2L_MOUT_EN_DISP_PATH0;
> } else {
> value = 0;
> }
> @@ -366,6 +376,10 @@ static unsigned int mtk_ddp_sel_in(const struct
> mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
> *addr = DISP_REG_CONFIG_DSI_SEL;
> value = DSI_SEL_IN_BLS;
> + } else if (cur == DDP_COMPONENT_OVL_2L0 &&
> +next == DDP_COMPONENT_RDMA0) {
> + *addr = MT8183_DISP_PATH0_SEL_IN;
> + value = DISP_PATH0_SEL_IN_OVL0_2L;
> } else {
> value = 0;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103217] Recent noveau causes errors with scilab 5.5.2 on NVIDIA G84GL [Quadro FX 570]
https://bugs.freedesktop.org/show_bug.cgi?id=103217 --- Comment #9 from jaimeallen --- Much thanks for the most recent innovation. I'm completely engaged with the post of https://icasinoreviews.info/1-dollar-deposit-casinos/for the difficulties. The tip of the composing is devoured by me with respect to innovation and cell phones. -- 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
