[Bug 206155] amdgpu several warnings while booting Fiji GPU, GPU not activated
https://bugzilla.kernel.org/show_bug.cgi?id=206155 Janpieter Sollie (janpieter.sol...@dommel.be) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Janpieter Sollie (janpieter.sol...@dommel.be) --- Bug is invalid - caused by a HW gpu failure (#206141), disabling those rings fixed it completely -- 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 206141] VCE UVD ring test failed -110
https://bugzilla.kernel.org/show_bug.cgi?id=206141 Janpieter Sollie (janpieter.sol...@dommel.be) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Janpieter Sollie (janpieter.sol...@dommel.be) --- Thank you Alex! You helped the environment by making it unnecessary to trash a GPU :p. Anyway, this bug is definitely solved, thank you all! If there's anything I could do to pay back for the support, let me know. Janpieter -- 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 v3] drm/dp_mst: Fix W=1 warnings
Hey, does this still need review?
On Tue, 2020-01-07 at 14:11 +0100, Benjamin Gaignard wrote:
> Le ven. 20 déc. 2019 à 15:03, Benjamin Gaignard
> a écrit :
> > Le lun. 16 déc. 2019 à 09:28, Benjamin Gaignard
> > a écrit :
> > > Le mer. 4 déc. 2019 à 17:47, Jani Nikula a
> > > écrit :
> > > > On Thu, 28 Nov 2019, Benjamin Gaignard
> > > > wrote:
> > > > > Fix the warnings that show up with W=1.
> > > > > They are all about unused but set variables.
> > > > > If functions returns are not used anymore make them void.
> > > > >
> > > > > Signed-off-by: Benjamin Gaignard
> > > > > ---
> > > > > CC: Jani Nikula
> > > > >
> > > > > changes in version 3:
> > > > > - remove the hunk that may conflict with c485e2c97dae
> > > > > ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
> > > > >
> > > > > changes in version 2:
> > > > > - fix indentations
> > > > > - when possible change functions prototype to void
> > > > >
> > > > > drivers/gpu/drm/drm_dp_mst_topology.c | 83 +--
> > > > >
> > > > > 1 file changed, 31 insertions(+), 52 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > index 1437bc46368b..d5cb5688b5dd 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > @@ -674,7 +674,6 @@ static bool drm_dp_sideband_msg_build(struct
> > > > > drm_dp_sideband_msg_rx *msg,
> > > > > u8 *replybuf, u8 replybuflen,
> > > > > bool hdr)
> > > > > {
> > > > > int ret;
> > > > > - u8 crc4;
> > > > >
> > > > > if (hdr) {
> > > > > u8 hdrlen;
> > > > > @@ -716,8 +715,6 @@ static bool drm_dp_sideband_msg_build(struct
> > > > > drm_dp_sideband_msg_rx *msg,
> > > > > }
> > > > >
> > > > > if (msg->curchunk_idx >= msg->curchunk_len) {
> > > > > - /* do CRC */
> > > > > - crc4 = drm_dp_msg_data_crc4(msg->chunk, msg-
> > > > > >curchunk_len - 1);
> > > >
> > > > Again, someone needs to check if crc4 should be *used* instead of
> > > > thrown
> > > > away. Blindly throwing stuff out is not the way to go.
> > >
> > > Hi Dave,
> > >
> >
> > + Lyude who has been hacking in this code recently
>
> gentle ping for the reviewers,
>
> Thanks,
> Benjamin
> > > Your are the original writer of this code, could you tell us if we can
> > > drop crc4
> > > ao if there is something else that I have misunderstood ?
> > >
> > > Thanks,
> > > Benjamin
> > >
> > > > BR,
> > > > Jani.
> > > >
> > > > > /* copy chunk into bigger msg */
> > > > > memcpy(&msg->msg[msg->curlen], msg->chunk, msg-
> > > > > >curchunk_len - 1);
> > > > > msg->curlen += msg->curchunk_len - 1;
> > > > > @@ -1014,7 +1011,7 @@ static bool drm_dp_sideband_parse_req(struct
> > > > > drm_dp_sideband_msg_rx *raw,
> > > > > }
> > > > > }
> > > > >
> > > > > -static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
> > > > > port_num, u32 offset, u8 num_bytes, u8 *bytes)
> > > > > +static void build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
> > > > > port_num, u32 offset, u8 num_bytes, u8 *bytes)
> > > > > {
> > > > > struct drm_dp_sideband_msg_req_body req;
> > > > >
> > > > > @@ -1024,17 +1021,14 @@ static int build_dpcd_write(struct
> > > > > drm_dp_sideband_msg_tx *msg, u8 port_num, u32
> > > > > req.u.dpcd_write.num_bytes = num_bytes;
> > > > > req.u.dpcd_write.bytes = bytes;
> > > > > drm_dp_encode_sideband_req(&req, msg);
> > > > > -
> > > > > - return 0;
> > > > > }
> > > > >
> > > > > -static int build_link_address(struct drm_dp_sideband_msg_tx *msg)
> > > > > +static void build_link_address(struct drm_dp_sideband_msg_tx *msg)
> > > > > {
> > > > > struct drm_dp_sideband_msg_req_body req;
> > > > >
> > > > > req.req_type = DP_LINK_ADDRESS;
> > > > > drm_dp_encode_sideband_req(&req, msg);
> > > > > - return 0;
> > > > > }
> > > > >
> > > > > static int build_enum_path_resources(struct drm_dp_sideband_msg_tx
> > > > > *msg, int port_num)
> > > > > @@ -1048,7 +1042,7 @@ static int build_enum_path_resources(struct
> > > > > drm_dp_sideband_msg_tx *msg, int por
> > > > > return 0;
> > > > > }
> > > > >
> > > > > -static int build_allocate_payload(struct drm_dp_sideband_msg_tx
> > > > > *msg, int port_num,
> > > > > +static void build_allocate_payload(struct drm_dp_sideband_msg_tx
> > > > > *msg, int port_num,
> > > > > u8 vcpi, uint16_t pbn,
> > > > > u8 number_sdp_streams,
> > > > > u8 *sdp_stream_sink)
> > > > > @@ -1064,10 +1058,9 @@ static int build_allocate_payload(struct
> > > > > drm_dp_sideband_msg_tx *msg, int port_n
> > > > > number_sdp_streams);
> > > > > drm_dp_encode_sideband_req(&req, msg);
>
Re: [PATCH -next] drm/nouveau/kms/nv50: remove set but not unused variable 'nv_connector'
Reviewed-by: Lyude Paul
On Fri, 2020-01-17 at 11:36 +0800, YueHaibing wrote:
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_pior_enable:
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1672:28: warning:
> variable nv_connector set but not used [-Wunused-but-set-variable]
>
> commit ac2d9275f371 ("drm/nouveau/kms/nv50-: Store the
> bpc we're using in nv50_head_atom") left behind this.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 5fabe2b..a82b354 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1669,7 +1669,6 @@ nv50_pior_enable(struct drm_encoder *encoder)
> {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
> - struct nouveau_connector *nv_connector;
> struct nv50_head_atom *asyh = nv50_head_atom(nv_crtc->base.state);
> struct nv50_core *core = nv50_disp(encoder->dev)->core;
> u8 owner = 1 << nv_crtc->index;
> @@ -1677,7 +1676,6 @@ nv50_pior_enable(struct drm_encoder *encoder)
>
> nv50_outp_acquire(nv_encoder);
>
> - nv_connector = nouveau_encoder_connector_get(nv_encoder);
> switch (asyh->or.bpc) {
> case 10: asyh->or.depth = 0x6; break;
> case 8: asyh->or.depth = 0x5; break;
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/1] drm/dp_mst: Handle SST-only branch device case
Pushed to drm-misc-fixes, thanks!
On Fri, 2020-01-17 at 14:03 +0800, Wayne Lin wrote:
> [Why]
> While handling LINK_ADDRESS reply, current code expects a peer device
> can handle sideband message once the peer device type is reported as
> DP_PEER_DEVICE_MST_BRANCHING. However, when the connected device is
> a SST branch case, it can't handle the sideband message(MST_CAP=0 in
> DPCD 00021h).
>
> Current code will try to send LINK_ADDRESS to SST branch device and end
> up with message timeout and monitor can't display normally. As the
> result of that, we should take SST branch device into account.
>
> [How]
> According to DP 1.4 spec, we can use Peer_Device_Type as
> DP_PEER_DEVICE_MST_BRANCHING and Message_Capability_Status as 0 to
> indicate peer device as a SST-only branch device.
>
> Fix following:
> - Add the function drm_dp_mst_is_dp_mst_end_device() to decide whether a
> peer device connected to a DFP is mst end device. Which also indicates
> if the peer device is capable of handling message or not.
> - Take SST-only branch device case into account in
> drm_dp_port_set_pdt() and add a new parameter 'new_mcs'. Take sst branch
> device case as the same case as DP_PEER_DEVICE_DP_LEGACY_CONV and
> DP_PEER_DEVICE_SST_SINK. All original handling logics remain.
> - Take SST-only branch device case into account in
> drm_dp_mst_port_add_connector().
> - Fix some parts in drm_dp_mst_handle_link_address_port() to have SST
> branch device case into consideration.
> - Fix the arguments of drm_dp_port_set_pdt() in
> drm_dp_mst_handle_conn_stat().
> - Have SST branch device also report
> connector_status_connected when the ddps is true
> in drm_dp_mst_detect_port()
> - Fix the arguments of drm_dp_port_set_pdt() in
> drm_dp_delayed_destroy_port()
>
> Changes since v1:(https://patchwork.kernel.org/patch/11323079/)
> * Squash previous patch into one patch and merge the commit message here.
> * Combine the if statements mentioned in comments
>
> Fixes: c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more
> locking")
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Lyude Paul
> Signed-off-by: Wayne Lin
> Reviewed-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 140 +++---
> 1 file changed, 80 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 79691c553182..c40a9bd63cfb 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1914,73 +1914,90 @@ static u8 drm_dp_calculate_rad(struct
> drm_dp_mst_port *port,
> return parent_lct + 1;
> }
>
> -static int drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8 new_pdt)
> +static bool drm_dp_mst_is_dp_mst_end_device(u8 pdt, bool mcs)
> +{
> + switch (pdt) {
> + case DP_PEER_DEVICE_DP_LEGACY_CONV:
> + case DP_PEER_DEVICE_SST_SINK:
> + return true;
> + case DP_PEER_DEVICE_MST_BRANCHING:
> + /* For sst branch device */
> + if (!mcs)
> + return true;
> +
> + return false;
> + }
> + return true;
> +}
> +
> +static int
> +drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8 new_pdt,
> + bool new_mcs)
> {
> struct drm_dp_mst_topology_mgr *mgr = port->mgr;
> struct drm_dp_mst_branch *mstb;
> u8 rad[8], lct;
> int ret = 0;
>
> - if (port->pdt == new_pdt)
> + if (port->pdt == new_pdt && port->mcs == new_mcs)
> return 0;
>
> /* Teardown the old pdt, if there is one */
> - switch (port->pdt) {
> - case DP_PEER_DEVICE_DP_LEGACY_CONV:
> - case DP_PEER_DEVICE_SST_SINK:
> - /*
> - * If the new PDT would also have an i2c bus, don't bother
> - * with reregistering it
> - */
> - if (new_pdt == DP_PEER_DEVICE_DP_LEGACY_CONV ||
> - new_pdt == DP_PEER_DEVICE_SST_SINK) {
> - port->pdt = new_pdt;
> - return 0;
> - }
> + if (port->pdt != DP_PEER_DEVICE_NONE) {
> + if (drm_dp_mst_is_dp_mst_end_device(port->pdt, port->mcs)) {
> + /*
> + * If the new PDT would also have an i2c bus,
> + * don't bother with reregistering it
> + */
> + if (new_pdt != DP_PEER_DEVICE_NONE &&
> + drm_dp_mst_is_dp_mst_end_device(new_pdt, new_mcs))
> {
> + port->pdt = new_pdt;
> + port->mcs = new_mcs;
> + return 0;
> + }
>
> - /* remove i2c over sideband */
> - drm_dp_mst_unregister_i2c_bus(&port->aux);
> - break;
> - case DP_PEER_DEVICE_MST_BRANCHING:
> - mutex_lock(&mgr->lock);
> - drm_dp_mst_topology_put_mstb(port->mstb);
[PATCH v4] drm/i915: Don't use VBT for detecting DPCD backlight controls
Despite the fact that the VBT appears to have a field for specifying
that a system is equipped with a panel that supports standard VESA
backlight controls over the DP AUX channel, so far every system we've
spotted DPCD backlight control support on doesn't actually set this
field correctly and all have it set to INTEL_BACKLIGHT_DISPLAY_DDI.
While we don't know the exact reason for this VBT misuse, talking with
some vendors indicated that there's a good number of laptop panels out
there that supposedly support both PWM backlight controls and DPCD
backlight controls as a workaround until Intel supports DPCD backlight
controls across platforms universally. This being said, the X1 Extreme
2nd Gen that I have here (note that Lenovo is not the hardware vendor
that informed us of this) PWM backlight controls are advertised, but
only DPCD controls actually function. I'm going to make an educated
guess here and say that on systems like this one, it's likely that PWM
backlight controls might have been intended to work but were never
really tested by QA.
Since we really need backlights to work without any extra module
parameters, let's take the risk here and rely on the standard DPCD caps
to tell us whether AUX backlight controls are supported or not. We still
check the VBT, just so we can print a debugging message on systems that
advertise DPCD backlight support on the panel but not in the VBT.
Changes since v3:
* Print a debugging message if we enable DPCD backlight control on a
device which doesn't report DPCD backlight controls in it's VBT,
instead of warning on custom panel backlight interfaces.
Signed-off-by: Lyude Paul
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376
Cc: Jani Nikula
Cc: Perry Yuan
Cc: AceLan Kao
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 77a759361c5c..0f8edc775375 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -328,15 +328,16 @@ intel_dp_aux_display_control_capable(struct
intel_connector *connector)
int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
{
struct intel_panel *panel = &intel_connector->panel;
- struct drm_i915_private *dev_priv = to_i915(intel_connector->base.dev);
+ enum intel_backlight_type type =
+ to_i915(intel_connector->base.dev)->vbt.backlight.type;
if (i915_modparams.enable_dpcd_backlight == 0 ||
(i915_modparams.enable_dpcd_backlight == -1 &&
- dev_priv->vbt.backlight.type !=
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE))
+!intel_dp_aux_display_control_capable(intel_connector)))
return -ENODEV;
- if (!intel_dp_aux_display_control_capable(intel_connector))
- return -ENODEV;
+ if (type != INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+ DRM_DEBUG_DRIVER("Ignoring VBT backlight type\n");
panel->backlight.setup = intel_dp_aux_setup_backlight;
panel->backlight.enable = intel_dp_aux_enable_backlight;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] dt-bindings: display: Convert a bunch of panels to DT schema
Convert all the 'simple' panels which match the constraints of the common panel-simple.yaml schema. This conversion is based on how the panels are documented. Some may turn out to be more complex once the schema is applied to actual dts files. Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Thierry Reding Cc: Sam Ravnborg Signed-off-by: Rob Herring --- v2: - Drop the individual schema files and use panel-simple.yaml - Drop DSI panels from conversion .../bindings/display/panel/auo,b080uan01.txt | 7 - .../bindings/display/panel/auo,b101aw03.txt | 7 - .../bindings/display/panel/auo,b101ean01.txt | 7 - .../bindings/display/panel/auo,b101xtn01.txt | 7 - .../bindings/display/panel/auo,b116xw03.txt | 7 - .../bindings/display/panel/auo,b133htn01.txt | 7 - .../bindings/display/panel/auo,b133xtn01.txt | 7 - .../bindings/display/panel/auo,g070vvn01.txt | 29 --- .../bindings/display/panel/auo,g101evn010.txt | 12 -- .../bindings/display/panel/auo,g104sn02.txt | 12 -- .../bindings/display/panel/auo,g133han01.txt | 7 - .../bindings/display/panel/auo,g185han01.txt | 7 - .../bindings/display/panel/auo,p320hvn03.txt | 8 - .../bindings/display/panel/auo,t215hvn01.txt | 7 - .../display/panel/avic,tm070ddh03.txt | 7 - .../display/panel/boe,hv070wsa-100.txt| 28 --- .../display/panel/boe,nv101wxmn51.txt | 7 - .../display/panel/boe,tv080wum-nl0.txt| 7 - .../display/panel/cdtech,s043wq26h-ct7.txt| 12 -- .../display/panel/cdtech,s070wv95-ct16.txt| 12 -- .../display/panel/chunghwa,claa070wp03xg.txt | 7 - .../display/panel/chunghwa,claa101wa01a.txt | 7 - .../display/panel/chunghwa,claa101wb03.txt| 7 - .../panel/dataimage,scf0700c48ggu18.txt | 8 - .../bindings/display/panel/dlc,dlc1010gig.txt | 12 -- .../bindings/display/panel/edt,et-series.txt | 55 - .../display/panel/evervision,vgg804821.txt| 12 -- .../display/panel/foxlink,fl500wvr00-a0t.txt | 7 - .../display/panel/friendlyarm,hd702e.txt | 32 --- .../display/panel/giantplus,gpg482739qs5.txt | 7 - .../display/panel/hannstar,hsd070pww1.txt | 7 - .../display/panel/hannstar,hsd100pxn1.txt | 7 - .../display/panel/hit,tx23d38vm0caa.txt | 7 - .../display/panel/innolux,at043tn24.txt | 7 - .../display/panel/innolux,at070tn92.txt | 7 - .../display/panel/innolux,g070y2-l01.txt | 12 -- .../display/panel/innolux,g101ice-l01.txt | 7 - .../display/panel/innolux,g121i1-l01.txt | 7 - .../display/panel/innolux,g121x1-l03.txt | 7 - .../display/panel/innolux,n116bge.txt | 7 - .../display/panel/innolux,n156bge-l21.txt | 7 - .../display/panel/innolux,p120zdg-bf1.txt | 22 -- .../display/panel/innolux,zj070na-01p.txt | 7 - .../display/panel/koe,tx14d24vm1bpa.txt | 42 .../display/panel/koe,tx31d200vm0baa.txt | 25 --- .../bindings/display/panel/kyo,tcg121xglp.txt | 7 - .../display/panel/lemaker,bl035-rgb-002.txt | 12 -- .../bindings/display/panel/lg,acx467akm-7.txt | 7 - .../bindings/display/panel/lg,lb070wv8.txt| 7 - .../display/panel/lg,ld070wx3-sl01.txt| 7 - .../display/panel/lg,lh500wx1-sd03.txt| 7 - .../display/panel/lg,lp079qx1-sp0v.txt| 7 - .../display/panel/lg,lp097qx1-spa1.txt| 7 - .../bindings/display/panel/lg,lp120up1.txt| 7 - .../bindings/display/panel/lg,lp129qe.txt | 7 - .../display/panel/mitsubishi,aa070mc01.txt| 7 - .../display/panel/nec,nl12880b20-05.txt | 8 - .../display/panel/nec,nl4827hc19-05b.txt | 7 - .../display/panel/netron-dy,e231732.txt | 7 - .../panel/newhaven,nhd-4.3-480272ef-atxl.txt | 7 - .../display/panel/nlt,nl192108ac18-02d.txt| 8 - .../bindings/display/panel/nvd,9128.txt | 7 - .../display/panel/okaya,rs800480t-7x0gp.txt | 7 - .../panel/olimex,lcd-olinuxino-43-ts.txt | 7 - .../display/panel/ontat,yx700wv03.txt | 7 - .../display/panel/ortustech,com37h3m05dtc.txt | 12 -- .../display/panel/ortustech,com37h3m99dtc.txt | 12 -- .../display/panel/ortustech,com43h4m85ulc.txt | 7 - .../panel/osddisplays,osd070t1718-19ts.txt| 12 -- .../panel/osddisplays,osd101t2045-53ts.txt| 11 - .../display/panel/panasonic,vvx10f004b00.txt | 7 - .../bindings/display/panel/panel-simple.yaml | 197 ++ .../display/panel/qiaodian,qd43003c0-40.txt | 7 - .../display/panel/rocktech,rk070er9427.txt| 25 --- .../display/panel/samsung,lsn122dl01-c01.txt | 7 - .../display/panel/samsung,ltn101nt05.txt | 7 - .../display/panel/samsung,ltn140at29-301.txt | 7 - .../display/panel/sharp,lq035q7db03.txt | 12 -- .../display/panel/sharp,lq070y3dg3b.txt | 12 -- .../display/panel/sharp,lq101k1ly04.txt | 7 - .../display/panel/sharp,lq123p1jx31.txt | 7 - .../display/panel/shelly,sca07010-bfn-lnn.t
[PATCH 2/2] drm/dp_mst: Fix clearing payload state on topology disable
The issues caused by:
64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr")
Prompted me to take a closer look at how we clear the payload state in
general when disabling the topology, and it turns out there's actually
two subtle issues here.
The first is that we're not grabbing &mgr.payload_lock when clearing the
payloads in drm_dp_mst_topology_mgr_set_mst(). Seeing as the canonical
lock order is &mgr.payload_lock -> &mgr.lock (because we always want
&mgr.lock to be the inner-most lock so topology validation always
works), this makes perfect sense. It also means that -technically- there
could be racing between someone calling
drm_dp_mst_topology_mgr_set_mst() to disable the topology, along with a
modeset occurring that's modifying the payload state at the same time.
The second is the more obvious issue that Wayne Lin discovered, that
we're not clearing proposed_payloads when disabling the topology.
I actually can't see any obvious places where the racing caused by the
first issue would break something, and it could be that some of our
higher-level locks already prevent this by happenstance, but better safe
then sorry. So, let's make it so that drm_dp_mst_topology_mgr_set_mst()
first grabs &mgr.payload_lock followed by &mgr.lock so that we never
race when modifying the payload state. Then, we also clear
proposed_payloads to fix the original issue of enabling a new topology
with a dirty payload state. This doesn't clear any of the drm_dp_vcpi
structures, but those are getting destroyed along with the ports anyway.
Cc: Sean Paul
Cc: Wayne Lin
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 89c2a7505cbd..58287f4c1baf 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3483,6 +3483,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
int ret = 0;
struct drm_dp_mst_branch *mstb = NULL;
+ mutex_lock(&mgr->payload_lock);
mutex_lock(&mgr->lock);
if (mst_state == mgr->mst_state)
goto out_unlock;
@@ -3541,7 +3542,10 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
/* this can fail if the device is gone */
drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0);
ret = 0;
- memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct
drm_dp_payload));
+ memset(mgr->payloads, 0,
+ mgr->max_payloads * sizeof(struct drm_dp_payload));
+ memset(mgr->proposed_vcpis, 0,
+ mgr->max_payloads * sizeof(void*));
mgr->payload_mask = 0;
set_bit(0, &mgr->payload_mask);
mgr->vcpi_mask = 0;
@@ -3550,6 +3554,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
out_unlock:
mutex_unlock(&mgr->lock);
+ mutex_unlock(&mgr->payload_lock);
if (mstb)
drm_dp_mst_topology_put_mstb(mstb);
return ret;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/dp_mst: Fix indenting in drm_dp_mst_topology_mgr_set_mst()
This has always bugged me but somehow I've never remembered to actually fix it. So let's do that. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 8fd85a33ed1b..89c2a7505cbd 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -3521,7 +3521,9 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms drm_dp_mst_topology_get_mstb(mgr->mst_primary); ret = drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, -DP_MST_EN | DP_UP_REQ_EN | DP_UPSTREAM_IS_SRC); +DP_MST_EN | +DP_UP_REQ_EN | +DP_UPSTREAM_IS_SRC); if (ret < 0) goto out_unlock; -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, amdkfd, scheduler, drm drm-next-5.6
Hi Dave, Daniel, Same PR as yesterday, this just adds a DP MST fix for the DSC code and a mutex init regression on top. The following changes since commit 688486a49cf500a193dfe15be9eb5aa468887769: Merge tag 'amd-drm-next-5.6-2020-01-10-dp-mst-dsc' of git://people.freedesktop.org/~agd5f/linux into drm-next (2020-01-13 17:14:34 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.6-2020-01-17 for you to fetch changes up to 7b19914383fc008a6b51871f18da72cf9aa43cae: drm/mst: Don't do atomic checks over disabled managers (2020-01-17 16:04:19 -0500) amd-drm-next-5.6-2020-01-17: amdgpu: - Fix 32 bit harder - Powerplay cleanups - VCN fixes for Arcturus - RAS fixes - eDP/DP fixes - SR-IOV fixes - Re-enable S/G display for PCO/RV2 - Free stolen memory after init on gmc10 - DF hashing optimizations for Arcturus - Properly handle runtime pm in sysfs and debugfs - Unify more GC programming between amdgpu and amdkfd - Golden settings updates for gfx10 - GDDR6 training fixes - Freesync fixes - DSC fixes - TMDS fixes - Renoir USB-C fixes - DC dml updates from hw team - Pollock support - Mutex init regresson fix amdkfd: - Unify more GC programming between amdgpu and amdkfd - Use KIQ to setup HIQ rather than using MMIO scheduler: - Documentation fixes - Improve job distribution with load sharing drm: - DP MST fix Aaron Liu (3): drm/amd/powerplay: update SMU12_DRIVER_IF_VERSION to 11 drm/amdgpu: update goldensetting for renoir drm/amdkfd: use kiq to load the mqd of hiq queue for gfx v9 (v6) Alex Deucher (11): drm/amdgpu/powerplay: fix warning in smu_v11_0.c drm/amdgpu/gfx9: remove unused sdma headers drm/amdgpu/display: set gpu vm flag for all asics which support it drm/amdgpu: enable S/G display on PCO and RV2 (v2) drm/amdgpu/display: set gpu vm flag for renoir drm/amdgpu/gmc10: remove dead code drm/amdgpu/gmc10: free stolen memory in late_init drm/amdgpu/psp: declare navi1x ta firmware drm/amdgpu/pm: properly handle runtime pm drm/amdgpu/debugfs: properly handle runtime pm drm/amdgpu/pm: clean up return types Alex Sierra (7): drm/amdgpu: Avoid reclaim fs while eviction lock drm/amdgpu: kiq pm4 function implementation for gfx_v9 drm/amdgpu: implement tlbs invalidate on gfx9 gfx10 drm/amdgpu: replace kcq enable/disable functions on gfx_v9 drm/amdgpu: export function to flush TLB via pasid drm/amdgpu: GPU TLB flush API moved to amdgpu_amdkfd drm/amdgpu: flush TLB functions removal from kfd2kgd interface Alvin Lee (3): drm/amd/display: Fix 300Hz Freesync bug drm/amd/display: Don't always set pstate true if dummy latency = 0 drm/amd/display: Enable double buffer for OTG_BLANK Amanda Liu (1): drm/amd/display: Clear state after exiting fixed active VRR state Anthony Koo (1): drm/amd/display: make PSR static screen entry within 30 ms Aric Cyr (4): drm/amd/display: 3.2.65 drm/amd/display: 3.2.66 drm/amd/display: 3.2.67 drm/amd/display: 3.2.68 Charlene Liu (1): drm/amd/display: rename _lvp to l_vp Chen Zhou (1): drm/amd/display: remove unnecessary conversion to bool Chris Park (1): drm/amd/display: Add default switch case for DCC Christian König (1): drm/amdgpu: drop amdgpu_job.owner Dmytro Laktyushkin (1): drm/amd/display: expand dml structs Eric Yang (1): drm/amd/display: fix chroma vp wa corner case Evan Quan (2): drm/amd/powerplay: cover the powerplay implementation details V3 drm/amd/powerplay: a quick fix for the deadlock issue below Flora Cui (1): drm/amdgpu: add header file for macro SZ_1M George Shen (1): drm/amd/display: Add w/a to reset PHY before link training in verify_link_cap Guchun Chen (2): drm/amdgpu: add MCUMC_ADDRT0 offset to ip header file drm/amdgpu: calculate MCUMC_ADDRT0 per asic's UMC offset Hawking Zhang (7): drm/amdgpu: add query_ras_error_count function for sdma v4 drm/amdgpu: support error reporting for sdma ip block drm/amdgpu: add ras_late_init and ras_fini for sdma v4 drm/amdgpu: read sdma edc counter to clear the counters drm/amdgpu: check sdma ras funcs pointer before accessing drm/amdgpu: check if driver should try recovery in ras recovery path drm/amdgpu: add arcturus to gpu recovery check code path Huang Rui (2): drm/amdkfd: use map_queues for hiq on gfx v10 as well drm/amdgpu: only set cp active field for kiq queue Jack Zhang (1): drm/amdgpu/sriov skip the update of SMU_TABLE_ACTIVITY_MONITOR_COEFF James Zhu (6): drm/amdgpu/vcn: support multiple-instance dpg pause mode drm/amdgpu/vcn: support multiple instance direct SRAM read and write (v2) drm/a
Re: [PATCH 1/4] drm/mst: Don't do atomic checks over disabled managers
On Fri, Jan 17, 2020 at 3:21 PM Lyude Paul wrote: > > Reviewed-by: Lyude Paul > Applied. I'll send a PR shortly. Thanks! Alex > On Thu, 2020-01-16 at 17:58 -0800, José Roberto de Souza wrote: > > When a main MST port is disconnected drivers should call > > drm_dp_mst_topology_mgr_set_mst() disabling the MST manager, this > > function will set manager mst_primary to NULL and it will cause the > > crash bellow on the next atomic check when trying to access > > mst_primary->port. > > > > As there is no use in running checks over managers that are not > > active this patch will skip it. > > > > [ 305.616450] [drm:drm_dp_mst_atomic_check] [MST PORT:cc2049e9] > > releases all VCPI slots > > [ 305.625085] [drm:drm_dp_mst_atomic_check] [MST PORT:020ab43e] > > releases all VCPI slots > > [ 305.633729] [drm:drm_dp_mst_atomic_check] [MST MGR:cdd467d4] mst > > state b67672eb VCPI avail=63 used=0 > > [ 305.644405] BUG: kernel NULL pointer dereference, address: > > 0030 > > [ 305.651448] #PF: supervisor read access in kernel mode > > [ 305.656640] #PF: error_code(0x) - not-present page > > [ 305.661807] PGD 0 P4D 0 > > [ 305.664396] Oops: [#1] PREEMPT SMP NOPTI > > [ 305.668789] CPU: 3 PID: 183 Comm: kworker/3:2 Not tainted 5.5.0-rc6+ > > #1404 > > [ 305.675703] Hardware name: Intel Corporation Ice Lake Client > > Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS > > ICLSFWR1.R00.3201.A00.1905140358 05/14/2019 > > [ 305.689425] Workqueue: events drm_dp_delayed_destroy_work > > [ 305.694874] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0 > > [ 305.700306] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 > > b0 b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> > > 8b 47 30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28 > > [ 305.719169] RSP: 0018:c90001687b58 EFLAGS: 00010246 > > [ 305.724434] RAX: RBX: 003f RCX: > > > > [ 305.731611] RDX: RSI: 88849fba8cb8 RDI: > > > > [ 305.738785] RBP: R08: R09: > > 0001 > > [ 305.745962] R10: c900016879a0 R11: c900016879a5 R12: > > > > [ 305.753139] R13: R14: 8884905c9bc0 R15: > > > > [ 305.760315] FS: () GS:88849fb8() > > knlGS: > > [ 305.768452] CS: 0010 DS: ES: CR0: 80050033 > > [ 305.774263] CR2: 0030 CR3: 05610006 CR4: > > 00760ee0 > > [ 305.781441] PKRU: 5554 > > [ 305.784228] Call Trace: > > [ 305.786739] intel_atomic_check+0xb2e/0x2560 [i915] > > [ 305.791678] ? printk+0x53/0x6a > > [ 305.794856] ? drm_atomic_check_only+0x3e/0x810 > > [ 305.799417] ? __drm_dbg+0x82/0x90 > > [ 305.802848] drm_atomic_check_only+0x56a/0x810 > > [ 305.807322] drm_atomic_commit+0xe/0x50 > > [ 305.811185] drm_client_modeset_commit_atomic+0x1e2/0x250 > > [ 305.816619] drm_client_modeset_commit_force+0x4d/0x180 > > [ 305.821921] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0 > > [ 305.827963] drm_fb_helper_set_par+0x2b/0x40 > > [ 305.832265] drm_fb_helper_hotplug_event.part.0+0xb2/0xd0 > > [ 305.837755] drm_kms_helper_hotplug_event+0x21/0x30 > > [ 305.842694] process_one_work+0x25b/0x5b0 > > [ 305.846735] worker_thread+0x4b/0x3b0 > > [ 305.850439] kthread+0x100/0x140 > > [ 305.853690] ? process_one_work+0x5b0/0x5b0 > > [ 305.857901] ? kthread_park+0x80/0x80 > > [ 305.861588] ret_from_fork+0x24/0x50 > > [ 305.865202] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek > > snd_hda_codec_generic i915 btusb btrtl btbcm btintel bluetooth prime_numbers > > snd_hda_intel snd_intel_dspcfg snd_hda_codec e1000e snd_hwdep snd_hda_core > > thunderbolt mei_hdcp mei_me asix cdc_ether x86_pkg_temp_thermal r8152 mei > > coretemp usbnet snd_pcm mii crct10dif_pclmul ptp crc32_pclmul ecdh_generic > > ghash_clmulni_intel pps_core ecc i2c_i801 intel_lpss_pci > > [ 305.903096] CR2: 0030 > > [ 305.906431] ---[ end trace 70ee364eed801cb0 ]--- > > [ 305.940816] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0 > > [ 305.946261] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 > > b0 b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> > > 8b 47 30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28 > > [ 305.965125] RSP: 0018:c90001687b58 EFLAGS: 00010246 > > [ 305.970382] RAX: RBX: 003f RCX: > > > > [ 305.977571] RDX: RSI: 88849fba8cb8 RDI: > > > > [ 305.984747] RBP: R08: R09: > > 0001 > > [ 305.991921] R10: c900016879a0 R11: c900016879a5 R12: > > > > [ 305.999099] R13: R14: 8884905c9bc0 R15: > > > > [ 306.006271] FS:
Re: [PATCH 2/4] drm/mst: Some style improvements in drm_dp_mst_topology_mgr_set_mst()
JFYI: I'm going to go ahead and push this patch by itself to drm-misc-next
since it applies cleanly, the other patches in this series don't depend on
this, and I'm about to send out a patch that modifies the code around these
hunks anyway.
On Thu, 2020-01-16 at 17:58 -0800, José Roberto de Souza wrote:
> Removing this lose code block and removing unnecessary bracket.
>
> Cc: Lyude Paul
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 38bf111e5f9b..e3a22362aaf2 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3491,6 +3491,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> drm_dp_mst_topology_mgr *mgr, bool ms
> mgr->mst_state = mst_state;
> /* set the device into MST mode */
> if (mst_state) {
> + struct drm_dp_payload reset_pay;
> +
> WARN_ON(mgr->mst_primary);
>
> /* get dpcd info */
> @@ -3521,16 +3523,12 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> drm_dp_mst_topology_mgr *mgr, bool ms
>
> ret = drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL,
>DP_MST_EN |
> DP_UP_REQ_EN | DP_UPSTREAM_IS_SRC);
> - if (ret < 0) {
> + if (ret < 0)
> goto out_unlock;
> - }
>
> - {
> - struct drm_dp_payload reset_pay;
> - reset_pay.start_slot = 0;
> - reset_pay.num_slots = 0x3f;
> - drm_dp_dpcd_write_payload(mgr, 0, &reset_pay);
> - }
> + reset_pay.start_slot = 0;
> + reset_pay.num_slots = 0x3f;
> + drm_dp_dpcd_write_payload(mgr, 0, &reset_pay);
>
> queue_work(system_long_wq, &mgr->work);
>
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206141] VCE UVD ring test failed -110
https://bugzilla.kernel.org/show_bug.cgi?id=206141 --- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Janpieter Sollie from comment #7) > Is it possible to disable the UVD/VCE engine on the original GPU? > I mean, it's not used anyway, so I might as well disable it completely to > avoid these errors. Yes. Set the amdgpu.ip_block_mask module parameter on the kernel command line in grub. Each bit refers to an IP. From your log: [3.987749] [drm] add ip block number 0 [3.987750] [drm] add ip block number 1 [3.987751] [drm] add ip block number 2 [3.987752] [drm] add ip block number 3 [3.987753] [drm] add ip block number 4 [3.987753] [drm] add ip block number 5 [3.987754] [drm] add ip block number 6 [3.987755] [drm] add ip block number 7 [3.987755] [drm] add ip block number 8 bits 7 and 8 are for uvd and vce, so you can append amdgpu.ip_block_mask=0x7f to only enable blocks 0-6. -- 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 v2 3/5] drm/mipi_dbi: Add support for display offsets
Hi Noralf.
If you could find time to review this patch it would be great.
I am reluctant to apply it until you have acked/reviewed it.
Thanks in advance,
Sam
On Wed, Jan 15, 2020 at 01:45:46PM +0100, Geert Uytterhoeven wrote:
> If the resolution of the TFT display is smaller than the maximum
> resolution supported by the display controller, the display may be
> connected to the driver output arrays with a horizontal and/or vertical
> offset, leading to a shifted image.
>
> Add support for specifying these offsets.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Sam Ravnborg
> ---
> v2:
> - Add Reviewed-by.
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 30 --
> include/drm/drm_mipi_dbi.h | 12
> 2 files changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 16bff1be4b8ac622..27fe81a53c88e338 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -238,6 +238,23 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> *fb,
> }
> EXPORT_SYMBOL(mipi_dbi_buf_copy);
>
> +static void mipi_dbi_set_window_address(struct mipi_dbi_dev *dbidev,
> + unsigned int xs, unsigned int xe,
> + unsigned int ys, unsigned int ye)
> +{
> + struct mipi_dbi *dbi = &dbidev->dbi;
> +
> + xs += dbidev->left_offset;
> + xe += dbidev->left_offset;
> + ys += dbidev->top_offset;
> + ye += dbidev->top_offset;
> +
> + mipi_dbi_command(dbi, MIPI_DCS_SET_COLUMN_ADDRESS, (xs >> 8) & 0xff,
> + xs & 0xff, (xe >> 8) & 0xff, xe & 0xff);
> + mipi_dbi_command(dbi, MIPI_DCS_SET_PAGE_ADDRESS, (ys >> 8) & 0xff,
> + ys & 0xff, (ye >> 8) & 0xff, ye & 0xff);
> +}
> +
> static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, struct drm_rect
> *rect)
> {
> struct drm_gem_object *gem = drm_gem_fb_get_obj(fb, 0);
> @@ -271,12 +288,8 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer
> *fb, struct drm_rect *rect)
> tr = cma_obj->vaddr;
> }
>
> - mipi_dbi_command(dbi, MIPI_DCS_SET_COLUMN_ADDRESS,
> - (rect->x1 >> 8) & 0xff, rect->x1 & 0xff,
> - ((rect->x2 - 1) >> 8) & 0xff, (rect->x2 - 1) & 0xff);
> - mipi_dbi_command(dbi, MIPI_DCS_SET_PAGE_ADDRESS,
> - (rect->y1 >> 8) & 0xff, rect->y1 & 0xff,
> - ((rect->y2 - 1) >> 8) & 0xff, (rect->y2 - 1) & 0xff);
> + mipi_dbi_set_window_address(dbidev, rect->x1, rect->x2 - 1, rect->y1,
> + rect->y2 - 1);
>
> ret = mipi_dbi_command_buf(dbi, MIPI_DCS_WRITE_MEMORY_START, tr,
> width * height * 2);
> @@ -366,10 +379,7 @@ static void mipi_dbi_blank(struct mipi_dbi_dev *dbidev)
>
> memset(dbidev->tx_buf, 0, len);
>
> - mipi_dbi_command(dbi, MIPI_DCS_SET_COLUMN_ADDRESS, 0, 0,
> - ((width - 1) >> 8) & 0xFF, (width - 1) & 0xFF);
> - mipi_dbi_command(dbi, MIPI_DCS_SET_PAGE_ADDRESS, 0, 0,
> - ((height - 1) >> 8) & 0xFF, (height - 1) & 0xFF);
> + mipi_dbi_set_window_address(dbidev, 0, width - 1, 0, height - 1);
> mipi_dbi_command_buf(dbi, MIPI_DCS_WRITE_MEMORY_START,
>(u8 *)dbidev->tx_buf, len);
>
> diff --git a/include/drm/drm_mipi_dbi.h b/include/drm/drm_mipi_dbi.h
> index 67c66f5ee591e80f..33f325f5af2b921f 100644
> --- a/include/drm/drm_mipi_dbi.h
> +++ b/include/drm/drm_mipi_dbi.h
> @@ -109,6 +109,18 @@ struct mipi_dbi_dev {
>*/
> unsigned int rotation;
>
> + /**
> + * @left_offset: Horizontal offset of the display relative to the
> + * controller's driver array
> + */
> + unsigned int left_offset;
> +
> + /**
> + * @top_offset: Vertical offset of the display relative to the
> + * controller's driver array
> + */
> + unsigned int top_offset;
> +
> /**
>* @backlight: backlight device (optional)
>*/
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "drm/dp_mst: Remove VCPI while disabling topology mgr"
On Fri, Jan 17, 2020 at 3:51 PM Lyude Paul wrote:
>
> This reverts commit 64e62bdf04ab8529f45ed0a85122c703035dec3a.
>
> This commit ends up causing some lockdep splats due to trying to grab the
> payload lock while holding the mgr's lock:
>
> [ 54.010099]
> [ 54.011765] ==
> [ 54.018670] WARNING: possible circular locking dependency detected
> [ 54.025577] 5.5.0-rc6-02274-g77381c23ee63 #47 Not tainted
> [ 54.031610] --
> [ 54.038516] kworker/1:6/1040 is trying to acquire lock:
> [ 54.044354] 888272af3228 (&mgr->payload_lock){+.+.}, at:
> drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.054957]
> [ 54.054957] but task is already holding lock:
> [ 54.061473] 888272af3060 (&mgr->lock){+.+.}, at:
> drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
> [ 54.071193]
> [ 54.071193] which lock already depends on the new lock.
> [ 54.071193]
> [ 54.080334]
> [ 54.080334] the existing dependency chain (in reverse order) is:
> [ 54.088697]
> [ 54.088697] -> #1 (&mgr->lock){+.+.}:
> [ 54.094440]__mutex_lock+0xc3/0x498
> [ 54.099015]drm_dp_mst_topology_get_port_validated+0x25/0x80
> [ 54.106018]drm_dp_update_payload_part1+0xa2/0x2e2
> [ 54.112051]intel_mst_pre_enable_dp+0x144/0x18f
> [ 54.117791]intel_encoders_pre_enable+0x63/0x70
> [ 54.123532]hsw_crtc_enable+0xa1/0x722
> [ 54.128396]intel_update_crtc+0x50/0x194
> [ 54.133455]skl_commit_modeset_enables+0x40c/0x540
> [ 54.139485]intel_atomic_commit_tail+0x5f7/0x130d
> [ 54.145418]intel_atomic_commit+0x2c8/0x2d8
> [ 54.150770]drm_atomic_helper_set_config+0x5a/0x70
> [ 54.156801]drm_mode_setcrtc+0x2ab/0x833
> [ 54.161862]drm_ioctl+0x2e5/0x424
> [ 54.166242]vfs_ioctl+0x21/0x2f
> [ 54.170426]do_vfs_ioctl+0x5fb/0x61e
> [ 54.175096]ksys_ioctl+0x55/0x75
> [ 54.179377]__x64_sys_ioctl+0x1a/0x1e
> [ 54.184146]do_syscall_64+0x5c/0x6d
> [ 54.188721]entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 54.194946]
> [ 54.194946] -> #0 (&mgr->payload_lock){+.+.}:
> [ 54.201463]
> [ 54.201463] other info that might help us debug this:
> [ 54.201463]
> [ 54.210410] Possible unsafe locking scenario:
> [ 54.210410]
> [ 54.217025]CPU0CPU1
> [ 54.222082]
> [ 54.227138] lock(&mgr->lock);
> [ 54.230643]lock(&mgr->payload_lock);
> [ 54.237742]lock(&mgr->lock);
> [ 54.244062] lock(&mgr->payload_lock);
> [ 54.248346]
> [ 54.248346] *** DEADLOCK ***
> [ 54.248346]
> [ 54.254959] 7 locks held by kworker/1:6/1040:
> [ 54.259822] #0: 888275c4f528 ((wq_completion)events){+.+.},
> at: worker_thread+0x455/0x6e2
> [ 54.269451] #1: c9000119beb0
> ((work_completion)(&(&dev_priv->hotplug.hotplug_work)->work)){+.+.},
> at: worker_thread+0x455/0x6e2
> [ 54.282768] #2: 888272a403f0 (&dev->mode_config.mutex){+.+.},
> at: i915_hotplug_work_func+0x4b/0x2be
> [ 54.293368] #3: 824fc6c0 (drm_connector_list_iter){.+.+},
> at: i915_hotplug_work_func+0x17e/0x2be
> [ 54.304061] #4: c9000119bc58 (crtc_ww_class_acquire){+.+.},
> at: drm_helper_probe_detect_ctx+0x40/0xfd
> [ 54.314855] #5: 888272a40470 (crtc_ww_class_mutex){+.+.}, at:
> drm_modeset_lock+0x74/0xe2
> [ 54.324385] #6: 888272af3060 (&mgr->lock){+.+.}, at:
> drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
> [ 54.334597]
> [ 54.334597] stack backtrace:
> [ 54.339464] CPU: 1 PID: 1040 Comm: kworker/1:6 Not tainted
> 5.5.0-rc6-02274-g77381c23ee63 #47
> [ 54.348893] Hardware name: Google Fizz/Fizz, BIOS
> Google_Fizz.10139.39.0 01/04/2018
> [ 54.357451] Workqueue: events i915_hotplug_work_func
> [ 54.362995] Call Trace:
> [ 54.365724] dump_stack+0x71/0x9c
> [ 54.369427] check_noncircular+0x91/0xbc
> [ 54.373809] ? __lock_acquire+0xc9e/0xf66
> [ 54.378286] ? __lock_acquire+0xc9e/0xf66
> [ 54.382763] ? lock_acquire+0x175/0x1ac
> [ 54.387048] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.393177] ? __mutex_lock+0xc3/0x498
> [ 54.397362] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.403492] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.409620] ? drm_dp_dpcd_access+0xd9/0x101
> [ 54.414390] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.420517] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.426645] ? intel_digital_port_connected+0x34d/0x35c
> [ 54.432482] ? intel_dp_detect+0x227/0x44e
> [ 54.437056] ? ww_mutex_lock+0x49/0x9a
> [ 54.441242] ? drm_helper_probe_detect_ctx+0x75/0xfd
> [ 54.446789] ? intel_encoder_hotplug+0x4b/0x97
> [ 54.451752] ? intel_ddi_hotplug+0x61/0x2e0
> [ 54.456423] ? mark_held_locks+0x53/0x68
> [ 54.460803] ? _raw_spi
[PATCH] Revert "drm/dp_mst: Remove VCPI while disabling topology mgr"
This reverts commit 64e62bdf04ab8529f45ed0a85122c703035dec3a.
This commit ends up causing some lockdep splats due to trying to grab the
payload lock while holding the mgr's lock:
[ 54.010099]
[ 54.011765] ==
[ 54.018670] WARNING: possible circular locking dependency detected
[ 54.025577] 5.5.0-rc6-02274-g77381c23ee63 #47 Not tainted
[ 54.031610] --
[ 54.038516] kworker/1:6/1040 is trying to acquire lock:
[ 54.044354] 888272af3228 (&mgr->payload_lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.054957]
[ 54.054957] but task is already holding lock:
[ 54.061473] 888272af3060 (&mgr->lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
[ 54.071193]
[ 54.071193] which lock already depends on the new lock.
[ 54.071193]
[ 54.080334]
[ 54.080334] the existing dependency chain (in reverse order) is:
[ 54.088697]
[ 54.088697] -> #1 (&mgr->lock){+.+.}:
[ 54.094440]__mutex_lock+0xc3/0x498
[ 54.099015]drm_dp_mst_topology_get_port_validated+0x25/0x80
[ 54.106018]drm_dp_update_payload_part1+0xa2/0x2e2
[ 54.112051]intel_mst_pre_enable_dp+0x144/0x18f
[ 54.117791]intel_encoders_pre_enable+0x63/0x70
[ 54.123532]hsw_crtc_enable+0xa1/0x722
[ 54.128396]intel_update_crtc+0x50/0x194
[ 54.133455]skl_commit_modeset_enables+0x40c/0x540
[ 54.139485]intel_atomic_commit_tail+0x5f7/0x130d
[ 54.145418]intel_atomic_commit+0x2c8/0x2d8
[ 54.150770]drm_atomic_helper_set_config+0x5a/0x70
[ 54.156801]drm_mode_setcrtc+0x2ab/0x833
[ 54.161862]drm_ioctl+0x2e5/0x424
[ 54.166242]vfs_ioctl+0x21/0x2f
[ 54.170426]do_vfs_ioctl+0x5fb/0x61e
[ 54.175096]ksys_ioctl+0x55/0x75
[ 54.179377]__x64_sys_ioctl+0x1a/0x1e
[ 54.184146]do_syscall_64+0x5c/0x6d
[ 54.188721]entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 54.194946]
[ 54.194946] -> #0 (&mgr->payload_lock){+.+.}:
[ 54.201463]
[ 54.201463] other info that might help us debug this:
[ 54.201463]
[ 54.210410] Possible unsafe locking scenario:
[ 54.210410]
[ 54.217025]CPU0CPU1
[ 54.222082]
[ 54.227138] lock(&mgr->lock);
[ 54.230643]lock(&mgr->payload_lock);
[ 54.237742]lock(&mgr->lock);
[ 54.244062] lock(&mgr->payload_lock);
[ 54.248346]
[ 54.248346] *** DEADLOCK ***
[ 54.248346]
[ 54.254959] 7 locks held by kworker/1:6/1040:
[ 54.259822] #0: 888275c4f528 ((wq_completion)events){+.+.},
at: worker_thread+0x455/0x6e2
[ 54.269451] #1: c9000119beb0
((work_completion)(&(&dev_priv->hotplug.hotplug_work)->work)){+.+.},
at: worker_thread+0x455/0x6e2
[ 54.282768] #2: 888272a403f0 (&dev->mode_config.mutex){+.+.},
at: i915_hotplug_work_func+0x4b/0x2be
[ 54.293368] #3: 824fc6c0 (drm_connector_list_iter){.+.+},
at: i915_hotplug_work_func+0x17e/0x2be
[ 54.304061] #4: c9000119bc58 (crtc_ww_class_acquire){+.+.},
at: drm_helper_probe_detect_ctx+0x40/0xfd
[ 54.314855] #5: 888272a40470 (crtc_ww_class_mutex){+.+.}, at:
drm_modeset_lock+0x74/0xe2
[ 54.324385] #6: 888272af3060 (&mgr->lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
[ 54.334597]
[ 54.334597] stack backtrace:
[ 54.339464] CPU: 1 PID: 1040 Comm: kworker/1:6 Not tainted
5.5.0-rc6-02274-g77381c23ee63 #47
[ 54.348893] Hardware name: Google Fizz/Fizz, BIOS
Google_Fizz.10139.39.0 01/04/2018
[ 54.357451] Workqueue: events i915_hotplug_work_func
[ 54.362995] Call Trace:
[ 54.365724] dump_stack+0x71/0x9c
[ 54.369427] check_noncircular+0x91/0xbc
[ 54.373809] ? __lock_acquire+0xc9e/0xf66
[ 54.378286] ? __lock_acquire+0xc9e/0xf66
[ 54.382763] ? lock_acquire+0x175/0x1ac
[ 54.387048] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.393177] ? __mutex_lock+0xc3/0x498
[ 54.397362] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.403492] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.409620] ? drm_dp_dpcd_access+0xd9/0x101
[ 54.414390] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.420517] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.426645] ? intel_digital_port_connected+0x34d/0x35c
[ 54.432482] ? intel_dp_detect+0x227/0x44e
[ 54.437056] ? ww_mutex_lock+0x49/0x9a
[ 54.441242] ? drm_helper_probe_detect_ctx+0x75/0xfd
[ 54.446789] ? intel_encoder_hotplug+0x4b/0x97
[ 54.451752] ? intel_ddi_hotplug+0x61/0x2e0
[ 54.456423] ? mark_held_locks+0x53/0x68
[ 54.460803] ? _raw_spin_unlock_irqrestore+0x3a/0x51
[ 54.466347] ? lockdep_hardirqs_on+0x187/0x1a4
[ 54.471310] ? drm_connector_list_iter_next+0x89/0x9a
[ 54.476953] ? i915_hotplug_work_func+0x206/0x2be
[ 54.482208] ? worker_thread+0x4d5/0x6e2
[ 54.486587] ? worke
Re: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology mgr
Yeah that's fine with me, I'll send out a revert for this in just a moment On Fri, 2020-01-17 at 15:43 -0500, Sean Paul wrote: > On Fri, Jan 17, 2020 at 3:27 PM Lyude Paul wrote: > > On Fri, 2020-01-17 at 11:19 -0500, Sean Paul wrote: > > > On Mon, Dec 9, 2019 at 12:56 AM Lin, Wayne wrote: > > > > > > > > > -Original Message- > > > > > From: Lyude Paul > > > > > Sent: Saturday, December 7, 2019 3:57 AM > > > > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org; > > > > > amd-...@lists.freedesktop.org > > > > > Cc: Kazlauskas, Nicholas ; Wentland, > > > > > Harry > > > > > ; Zuo, Jerry ; > > > > > sta...@vger.kernel.org > > > > > Subject: Re: [PATCH v2] drm/dp_mst: Remove VCPI while disabling > > > > > topology > > > > > mgr > > > > > > > > > > On Fri, 2019-12-06 at 14:24 -0500, Lyude Paul wrote: > > > > > > Reviewed-by: Lyude Paul > > > > > > > > > > > > I'll go ahead and push this to drm-misc-next-fixes right now, > > > > > > thanks! > > > > > > > > > > Whoops-meant to say drm-misc-next here, anyway, pushed! > > > > Thanks for your time! > > > > > > > > > > I'm getting the following warning on unplug with this patch: > > > > > \snip > > > I think I've got a better fix for this that should avoid that problem, > > I'll > > write up a patch and send it out in a bit > > Thanks Lyude! Should we revert this patch for the time being? > > > -- > > Cheers, > > Lyude Paul > > -- Cheers, Lyude Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology mgr
On Fri, Jan 17, 2020 at 3:27 PM Lyude Paul wrote: > > On Fri, 2020-01-17 at 11:19 -0500, Sean Paul wrote: > > On Mon, Dec 9, 2019 at 12:56 AM Lin, Wayne wrote: > > > > > > > > > > -Original Message- > > > > From: Lyude Paul > > > > Sent: Saturday, December 7, 2019 3:57 AM > > > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org; > > > > amd-...@lists.freedesktop.org > > > > Cc: Kazlauskas, Nicholas ; Wentland, Harry > > > > ; Zuo, Jerry ; > > > > sta...@vger.kernel.org > > > > Subject: Re: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology > > > > mgr > > > > > > > > On Fri, 2019-12-06 at 14:24 -0500, Lyude Paul wrote: > > > > > Reviewed-by: Lyude Paul > > > > > > > > > > I'll go ahead and push this to drm-misc-next-fixes right now, thanks! > > > > > > > > Whoops-meant to say drm-misc-next here, anyway, pushed! > > > Thanks for your time! > > > > > > > I'm getting the following warning on unplug with this patch: > > \snip > > I think I've got a better fix for this that should avoid that problem, I'll > write up a patch and send it out in a bit Thanks Lyude! Should we revert this patch for the time being? > > > -- > Cheers, > Lyude Paul > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology mgr
On Fri, 2020-01-17 at 11:19 -0500, Sean Paul wrote:
> On Mon, Dec 9, 2019 at 12:56 AM Lin, Wayne wrote:
> >
> >
> > > -Original Message-
> > > From: Lyude Paul
> > > Sent: Saturday, December 7, 2019 3:57 AM
> > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> > > amd-...@lists.freedesktop.org
> > > Cc: Kazlauskas, Nicholas ; Wentland, Harry
> > > ; Zuo, Jerry ;
> > > sta...@vger.kernel.org
> > > Subject: Re: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology
> > > mgr
> > >
> > > On Fri, 2019-12-06 at 14:24 -0500, Lyude Paul wrote:
> > > > Reviewed-by: Lyude Paul
> > > >
> > > > I'll go ahead and push this to drm-misc-next-fixes right now, thanks!
> > >
> > > Whoops-meant to say drm-misc-next here, anyway, pushed!
> > Thanks for your time!
> >
>
> I'm getting the following warning on unplug with this patch:
>
> [ 54.010099]
> [ 54.011765] ==
> [ 54.018670] WARNING: possible circular locking dependency detected
> [ 54.025577] 5.5.0-rc6-02274-g77381c23ee63 #47 Not tainted
> [ 54.031610] --
> [ 54.038516] kworker/1:6/1040 is trying to acquire lock:
> [ 54.044354] 888272af3228 (&mgr->payload_lock){+.+.}, at:
> drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.054957]
> [ 54.054957] but task is already holding lock:
> [ 54.061473] 888272af3060 (&mgr->lock){+.+.}, at:
> drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
> [ 54.071193]
> [ 54.071193] which lock already depends on the new lock.
> [ 54.071193]
> [ 54.080334]
> [ 54.080334] the existing dependency chain (in reverse order) is:
> [ 54.088697]
> [ 54.088697] -> #1 (&mgr->lock){+.+.}:
> [ 54.094440]__mutex_lock+0xc3/0x498
> [ 54.099015]drm_dp_mst_topology_get_port_validated+0x25/0x80
> [ 54.106018]drm_dp_update_payload_part1+0xa2/0x2e2
> [ 54.112051]intel_mst_pre_enable_dp+0x144/0x18f
> [ 54.117791]intel_encoders_pre_enable+0x63/0x70
> [ 54.123532]hsw_crtc_enable+0xa1/0x722
> [ 54.128396]intel_update_crtc+0x50/0x194
> [ 54.133455]skl_commit_modeset_enables+0x40c/0x540
> [ 54.139485]intel_atomic_commit_tail+0x5f7/0x130d
> [ 54.145418]intel_atomic_commit+0x2c8/0x2d8
> [ 54.150770]drm_atomic_helper_set_config+0x5a/0x70
> [ 54.156801]drm_mode_setcrtc+0x2ab/0x833
> [ 54.161862]drm_ioctl+0x2e5/0x424
> [ 54.166242]vfs_ioctl+0x21/0x2f
> [ 54.170426]do_vfs_ioctl+0x5fb/0x61e
> [ 54.175096]ksys_ioctl+0x55/0x75
> [ 54.179377]__x64_sys_ioctl+0x1a/0x1e
> [ 54.184146]do_syscall_64+0x5c/0x6d
> [ 54.188721]entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 54.194946]
> [ 54.194946] -> #0 (&mgr->payload_lock){+.+.}:
> [ 54.201463]
> [ 54.201463] other info that might help us debug this:
> [ 54.201463]
> [ 54.210410] Possible unsafe locking scenario:
> [ 54.210410]
> [ 54.217025]CPU0CPU1
> [ 54.222082]
> [ 54.227138] lock(&mgr->lock);
> [ 54.230643]lock(&mgr->payload_lock);
> [ 54.237742]lock(&mgr->lock);
> [ 54.244062] lock(&mgr->payload_lock);
> [ 54.248346]
> [ 54.248346] *** DEADLOCK ***
> [ 54.248346]
> [ 54.254959] 7 locks held by kworker/1:6/1040:
> [ 54.259822] #0: 888275c4f528 ((wq_completion)events){+.+.},
> at: worker_thread+0x455/0x6e2
> [ 54.269451] #1: c9000119beb0
> ((work_completion)(&(&dev_priv->hotplug.hotplug_work)->work)){+.+.},
> at: worker_thread+0x455/0x6e2
> [ 54.282768] #2: 888272a403f0 (&dev->mode_config.mutex){+.+.},
> at: i915_hotplug_work_func+0x4b/0x2be
> [ 54.293368] #3: 824fc6c0 (drm_connector_list_iter){.+.+},
> at: i915_hotplug_work_func+0x17e/0x2be
> [ 54.304061] #4: c9000119bc58 (crtc_ww_class_acquire){+.+.},
> at: drm_helper_probe_detect_ctx+0x40/0xfd
> [ 54.314855] #5: 888272a40470 (crtc_ww_class_mutex){+.+.}, at:
> drm_modeset_lock+0x74/0xe2
> [ 54.324385] #6: 888272af3060 (&mgr->lock){+.+.}, at:
> drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
> [ 54.334597]
> [ 54.334597] stack backtrace:
> [ 54.339464] CPU: 1 PID: 1040 Comm: kworker/1:6 Not tainted
> 5.5.0-rc6-02274-g77381c23ee63 #47
> [ 54.348893] Hardware name: Google Fizz/Fizz, BIOS
> Google_Fizz.10139.39.0 01/04/2018
> [ 54.357451] Workqueue: events i915_hotplug_work_func
> [ 54.362995] Call Trace:
> [ 54.365724] dump_stack+0x71/0x9c
> [ 54.369427] check_noncircular+0x91/0xbc
> [ 54.373809] ? __lock_acquire+0xc9e/0xf66
> [ 54.378286] ? __lock_acquire+0xc9e/0xf66
> [ 54.382763] ? lock_acquire+0x175/0x1ac
> [ 54.387048] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.393177] ? __mutex_lock+0xc3/0x498
> [ 54.397362] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.403492]
Re: [PATCH v9 12/18] drm/dp_mst: Add branch bandwidth validation to MST atomic check
fwiw - https://patchwork.freedesktop.org/patch/349111/ is the proper fix that I was talking about, we should probably go with that one instead if you haven't already pushed this On Fri, 2020-01-17 at 10:39 -0500, Sean Paul wrote: > On Fri, Jan 17, 2020 at 10:26 AM Mikita Lipski wrote: > > > > > > On 1/17/20 10:09 AM, Sean Paul wrote: > > > On Fri, Dec 13, 2019 at 3:09 PM wrote: > > > > From: Mikita Lipski > > > > > > > > > > Hi Mikita, > > > Unfortunately this patch causes a crash on my i915 device when I > > > unplug my MST hub. The panic is below. > > > > Hi Sean, > > > > I thought this issue was fixed by Wayne Lin in > > https://patchwork.freedesktop.org/patch/346736/?series=71388&rev=1 > > but now I checked it seems it never got pushed. I will resend Wayne's > > patch once again. > > > > No need to resend, I can push Wayne's patch. > > Thanks for the pointer, > > Sean > > > Thanks > > Mikita > > > [ 38.514014] BUG: kernel NULL pointer dereference, address: > > > 0030 > > > [ 38.521801] #PF: supervisor read access in kernel mode > > > [ 38.527556] #PF: error_code(0x) - not-present page > > > [ 38.533299] PGD 0 P4D 0 > > > [ 38.536127] Oops: [#1] PREEMPT SMP PTI > > > [ 38.540798] CPU: 1 PID: 1324 Comm: DrmThread Not tainted > > > 5.5.0-rc6-02273-g9bb4096398e7 #36 > > > [ 38.550040] Hardware name: Google Fizz/Fizz, BIOS > > > Google_Fizz.10139.39.0 01/04/2018 > > > [ 38.558606] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 > > > [ 38.565418] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 > > > 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d > > > 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 > > > 18 4c > > > [ 38.586422] RSP: 0018:c9000139f9d8 EFLAGS: 00010282 > > > [ 38.592264] RAX: RBX: 888272aeac88 RCX: > > > 888236f529e0 > > > [ 38.600242] RDX: 888272aeac88 RSI: 888236f529e0 RDI: > > > > > > [ 38.608220] RBP: c9000139fa00 R08: 0031 R09: > > > 000e > > > [ 38.616198] R10: 888236f529e8 R11: 8882621f3440 R12: > > > > > > [ 38.624176] R13: 888236f529d0 R14: 0030 R15: > > > 888236f529e0 > > > [ 38.632153] FS: 7cd9229ce700() GS:888276c8() > > > knlGS: > > > [ 38.641193] CS: 0010 DS: ES: CR0: 80050033 > > > [ 38.647616] CR2: 0030 CR3: 0002618e8004 CR4: > > > 003606e0 > > > [ 38.655593] Call Trace: > > > [ 38.658329] drm_dp_mst_atomic_check+0x152/0x16d > > > [ 38.663484] intel_atomic_check+0xcfe/0x1e6f > > > [ 38.668259] ? trace_hardirqs_on+0x28/0x3d > > > [ 38.672835] ? intel_pipe_config_compare+0x1b38/0x1b38 > > > [ 38.678580] drm_atomic_check_only+0x5ab/0x70f > > > [ 38.683547] ? drm_atomic_set_crtc_for_connector+0xf5/0x102 > > > [ 38.689778] ? drm_atomic_helper_shutdown+0xb6/0xb6 > > > [ 38.695221] drm_atomic_commit+0x18/0x53 > > > [ 38.699604] drm_atomic_helper_set_config+0x5a/0x70 > > > [ 38.705057] drm_mode_setcrtc+0x2ab/0x833 > > > [ 38.709537] ? rcu_read_unlock+0x57/0x57 > > > [ 38.713920] ? drm_mode_getcrtc+0x173/0x173 > > > [ 38.718594] drm_ioctl+0x2e5/0x424 > > > [ 38.722392] ? drm_mode_getcrtc+0x173/0x173 > > > [ 38.727069] vfs_ioctl+0x21/0x2f > > > [ 38.730675] do_vfs_ioctl+0x5fb/0x61e > > > [ 38.734766] ksys_ioctl+0x55/0x75 > > > [ 38.738469] __x64_sys_ioctl+0x1a/0x1e > > > [ 38.742659] do_syscall_64+0x5c/0x6d > > > [ 38.746653] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > [ 38.752298] RIP: 0033:0x7cd92552d497 > > > [ 38.756291] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 > > > 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 > > > 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 > > > 01 48 > > > [ 38.777296] RSP: 002b:7cd9229cd698 EFLAGS: 0246 ORIG_RAX: > > > 0010 > > > [ 38.785762] RAX: ffda RBX: 20323373da80 RCX: > > > 7cd92552d497 > > > [ 38.793740] RDX: 7cd9229cd6d0 RSI: c06864a2 RDI: > > > 001c > > > [ 38.801717] RBP: 7cd9229cd6c0 R08: R09: > > > > > > [ 38.809693] R10: R11: 0246 R12: > > > 001c > > > [ 38.817670] R13: R14: 7cd9229cd6d0 R15: > > > c06864a2 > > > [ 38.825642] Modules linked in: xt_nat cdc_ether r8152 bridge stp > > > llc usbhid btusb btrtl btbcm btintel bluetooth asix usbnet > > > ecdh_generic ecc mii snd_soc_hdac_hdmi snd_soc_dmic xhci_pci xhci_hcd > > > snd_soc_skl snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core > > > snd_intel_dspcfg snd_hda_core usbcore usb_common acpi_als kfifo_buf > > > industrialio xt_MASQUERADE iptable_nat nf_nat xt_mark fuse > > > ip6table_filter iwlmvm mac80211 r8169 realtek iwlwifi lzo_rle > > > lzo_compress
Re: [PATCH v3 4/5] drm/i915: Don't use VBT for detecting DPCD backlight controls
On Fri, 2020-01-17 at 13:36 +0200, Jani Nikula wrote:
> On Thu, 16 Jan 2020, Lyude Paul wrote:
> > Despite the fact that the VBT appears to have a field for specifying
> > that a system is equipped with a panel that supports standard VESA
> > backlight controls over the DP AUX channel, so far every system we've
> > spotted DPCD backlight control support on doesn't actually set this
> > field correctly and all have it set to INTEL_BACKLIGHT_DISPLAY_DDI.
> >
> > While we don't know the exact reason for this VBT misuse, talking with
> > some vendors indicated that there's a good number of laptop panels out
> > there that supposedly support both PWM backlight controls and DPCD
> > backlight controls as a workaround until Intel supports DPCD backlight
> > controls across platforms universally. This being said, the X1 Extreme
> > 2nd Gen that I have here (note that Lenovo is not the hardware vendor
> > that informed us of this) PWM backlight controls are advertised, but
> > only DPCD controls actually function. I'm going to make an educated
> > guess here and say that on systems like this one, it's likely that PWM
> > backlight controls might have been intended to work but were never
> > really tested by QA.
> >
> > Since we really need backlights to work without any extra module
> > parameters, let's take the risk here and rely on the standard DPCD caps
> > to tell us whether AUX backlight controls are supported or not. We still
> > check the VBT, but only to make sure that we don't enable DPCD backlight
> > controls on a panel that uses something other then the standard VESA
> > interfaces over AUX. Since panels using such non-standard interfaces
> > should probably have support added to i915, we'll print a warning when
> > seeing this in the VBT. We can remove this warning later if we end up
> > adding support for any custom backlight interfaces.
> >
> > Signed-off-by: Lyude Paul
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376
> > Cc: Jani Nikula
> > Cc: Perry Yuan
> > Cc: AceLan Kao
> > ---
> > .../drm/i915/display/intel_dp_aux_backlight.c| 16 ++--
> > 1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index 77a759361c5c..3002b600635f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -330,13 +330,17 @@ int intel_dp_aux_init_backlight_funcs(struct
> > intel_connector *intel_connector)
> > struct intel_panel *panel = &intel_connector->panel;
> > struct drm_i915_private *dev_priv = to_i915(intel_connector-
> > >base.dev);
> >
> > - if (i915_modparams.enable_dpcd_backlight == 0 ||
> > - (i915_modparams.enable_dpcd_backlight == -1 &&
> > - dev_priv->vbt.backlight.type !=
> > INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE))
> > - return -ENODEV;
> > -
> > - if (!intel_dp_aux_display_control_capable(intel_connector))
> > + if (i915_modparams.enable_dpcd_backlight == 0)
> > return -ENODEV;
> > + if (i915_modparams.enable_dpcd_backlight == -1) {
> > + if (dev_priv->vbt.backlight.type
> > + == INTEL_BACKLIGHT_PANEL_DRIVER_INTERFACE) {
> > + DRM_WARN("VBT says panel uses custom panel driver
> > interface, not using DPCD backlight controls\n");
> > + return -ENODEV;
> > + }
> > + if (!intel_dp_aux_display_control_capable(intel_connector))
> > + return -ENODEV;
>
> Functionally, I'm fine with trying this. But perhaps we should check aux
> and early return first, and then check what vbt says, to reduce the
> dmesg noise.
>
> I'll probably want to see a debug message if we're enabling aux
> backlight even if dev_priv->vbt.backlight.type !=
> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE. It's the kind of debug trace
> you'll really want to get first.
Good point, I'll send a respin of this patch with those changes
>
> BR,
> Jani.
>
>
>
> > + }
> >
> > panel->backlight.setup = intel_dp_aux_setup_backlight;
> > panel->backlight.enable = intel_dp_aux_enable_backlight;
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/mst: Don't do atomic checks over disabled managers
Reviewed-by: Lyude Paul On Thu, 2020-01-16 at 17:58 -0800, José Roberto de Souza wrote: > When a main MST port is disconnected drivers should call > drm_dp_mst_topology_mgr_set_mst() disabling the MST manager, this > function will set manager mst_primary to NULL and it will cause the > crash bellow on the next atomic check when trying to access > mst_primary->port. > > As there is no use in running checks over managers that are not > active this patch will skip it. > > [ 305.616450] [drm:drm_dp_mst_atomic_check] [MST PORT:cc2049e9] > releases all VCPI slots > [ 305.625085] [drm:drm_dp_mst_atomic_check] [MST PORT:020ab43e] > releases all VCPI slots > [ 305.633729] [drm:drm_dp_mst_atomic_check] [MST MGR:cdd467d4] mst > state b67672eb VCPI avail=63 used=0 > [ 305.644405] BUG: kernel NULL pointer dereference, address: > 0030 > [ 305.651448] #PF: supervisor read access in kernel mode > [ 305.656640] #PF: error_code(0x) - not-present page > [ 305.661807] PGD 0 P4D 0 > [ 305.664396] Oops: [#1] PREEMPT SMP NOPTI > [ 305.668789] CPU: 3 PID: 183 Comm: kworker/3:2 Not tainted 5.5.0-rc6+ > #1404 > [ 305.675703] Hardware name: Intel Corporation Ice Lake Client > Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS > ICLSFWR1.R00.3201.A00.1905140358 05/14/2019 > [ 305.689425] Workqueue: events drm_dp_delayed_destroy_work > [ 305.694874] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0 > [ 305.700306] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 > b0 b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> > 8b 47 30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28 > [ 305.719169] RSP: 0018:c90001687b58 EFLAGS: 00010246 > [ 305.724434] RAX: RBX: 003f RCX: > > [ 305.731611] RDX: RSI: 88849fba8cb8 RDI: > > [ 305.738785] RBP: R08: R09: > 0001 > [ 305.745962] R10: c900016879a0 R11: c900016879a5 R12: > > [ 305.753139] R13: R14: 8884905c9bc0 R15: > > [ 305.760315] FS: () GS:88849fb8() > knlGS: > [ 305.768452] CS: 0010 DS: ES: CR0: 80050033 > [ 305.774263] CR2: 0030 CR3: 05610006 CR4: > 00760ee0 > [ 305.781441] PKRU: 5554 > [ 305.784228] Call Trace: > [ 305.786739] intel_atomic_check+0xb2e/0x2560 [i915] > [ 305.791678] ? printk+0x53/0x6a > [ 305.794856] ? drm_atomic_check_only+0x3e/0x810 > [ 305.799417] ? __drm_dbg+0x82/0x90 > [ 305.802848] drm_atomic_check_only+0x56a/0x810 > [ 305.807322] drm_atomic_commit+0xe/0x50 > [ 305.811185] drm_client_modeset_commit_atomic+0x1e2/0x250 > [ 305.816619] drm_client_modeset_commit_force+0x4d/0x180 > [ 305.821921] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0 > [ 305.827963] drm_fb_helper_set_par+0x2b/0x40 > [ 305.832265] drm_fb_helper_hotplug_event.part.0+0xb2/0xd0 > [ 305.837755] drm_kms_helper_hotplug_event+0x21/0x30 > [ 305.842694] process_one_work+0x25b/0x5b0 > [ 305.846735] worker_thread+0x4b/0x3b0 > [ 305.850439] kthread+0x100/0x140 > [ 305.853690] ? process_one_work+0x5b0/0x5b0 > [ 305.857901] ? kthread_park+0x80/0x80 > [ 305.861588] ret_from_fork+0x24/0x50 > [ 305.865202] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek > snd_hda_codec_generic i915 btusb btrtl btbcm btintel bluetooth prime_numbers > snd_hda_intel snd_intel_dspcfg snd_hda_codec e1000e snd_hwdep snd_hda_core > thunderbolt mei_hdcp mei_me asix cdc_ether x86_pkg_temp_thermal r8152 mei > coretemp usbnet snd_pcm mii crct10dif_pclmul ptp crc32_pclmul ecdh_generic > ghash_clmulni_intel pps_core ecc i2c_i801 intel_lpss_pci > [ 305.903096] CR2: 0030 > [ 305.906431] ---[ end trace 70ee364eed801cb0 ]--- > [ 305.940816] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0 > [ 305.946261] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 > b0 b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> > 8b 47 30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28 > [ 305.965125] RSP: 0018:c90001687b58 EFLAGS: 00010246 > [ 305.970382] RAX: RBX: 003f RCX: > > [ 305.977571] RDX: RSI: 88849fba8cb8 RDI: > > [ 305.984747] RBP: R08: R09: > 0001 > [ 305.991921] R10: c900016879a0 R11: c900016879a5 R12: > > [ 305.999099] R13: R14: 8884905c9bc0 R15: > > [ 306.006271] FS: () GS:88849fb8() > knlGS: > [ 306.014407] CS: 0010 DS: ES: CR0: 80050033 > [ 306.020185] CR2: 0030 CR3: 00048b3aa003 CR4: > 00760ee0 > [ 306.027404] PKRU: 5554 > [ 306.030127] BUG: sleeping
Re: [PATCH 2/4] drm/mst: Some style improvements in drm_dp_mst_topology_mgr_set_mst()
Reviewed-by: Lyude Paul
On Thu, 2020-01-16 at 17:58 -0800, José Roberto de Souza wrote:
> Removing this lose code block and removing unnecessary bracket.
>
> Cc: Lyude Paul
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 38bf111e5f9b..e3a22362aaf2 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3491,6 +3491,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> drm_dp_mst_topology_mgr *mgr, bool ms
> mgr->mst_state = mst_state;
> /* set the device into MST mode */
> if (mst_state) {
> + struct drm_dp_payload reset_pay;
> +
> WARN_ON(mgr->mst_primary);
>
> /* get dpcd info */
> @@ -3521,16 +3523,12 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> drm_dp_mst_topology_mgr *mgr, bool ms
>
> ret = drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL,
>DP_MST_EN |
> DP_UP_REQ_EN | DP_UPSTREAM_IS_SRC);
> - if (ret < 0) {
> + if (ret < 0)
> goto out_unlock;
> - }
>
> - {
> - struct drm_dp_payload reset_pay;
> - reset_pay.start_slot = 0;
> - reset_pay.num_slots = 0x3f;
> - drm_dp_dpcd_write_payload(mgr, 0, &reset_pay);
> - }
> + reset_pay.start_slot = 0;
> + reset_pay.num_slots = 0x3f;
> + drm_dp_dpcd_write_payload(mgr, 0, &reset_pay);
>
> queue_work(system_long_wq, &mgr->work);
>
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #11 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- Dota2? (vulkan and GL) CS:GO? (GL) Those games are free. -- 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: [Bug 206231] R9 280X low performance with all games
Dota2? (vulkan and GL) CS:GO? (GL) Those games are free. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 206231] R9 280X low performance with all games
Wow, this from the first tomb raider, the one from 2013!! (7 years ago). Sorry I read the emails in the wrong order. I don't know own this game, sorry. Another game perhaps? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #10 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- Wow, this from the first tomb raider, the one from 2013!! (7 years ago). Sorry I read the emails in the wrong order. I don't know own this game, sorry. Another game perhaps? -- 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 0/6] video: fbdev: controlfb: small cleanup
Hi Bartlomiej On Thu, Jan 16, 2020 at 03:08:54PM +0100, Bartlomiej Zolnierkiewicz wrote: > Hi, > > Small cleanup for controlfb driver: > > - fix sparse warnings > - remove not working module support > - add COMPILE_TEST support > - remove redundant function prototypes Nice cleanup - with a few comments. The last three patches are the good ones. With my comments considered - and then up to you if you cahnge anything - then all patches are: Acked-by: Sam Ravnborg > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > > > Bartlomiej Zolnierkiewicz (6): > video: fbdev: controlfb: fix sparse warning about using incorrect type > video: fbdev: controlfb: remove obsolete module support > video: fbdev: controlfb: add COMPILE_TEST support > video: fbdev: controlfb: remove function prototypes part #1 > video: fbdev: controlfb: remove function prototypes part #2 > video: fbdev: controlfb: remove function prototypes part #3 > > drivers/video/fbdev/Kconfig | 2 +- > drivers/video/fbdev/controlfb.c | 810 +++- > 2 files changed, 383 insertions(+), 429 deletions(-) > > -- > 2.24.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
[PATCH v3 05/12] drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-s...@poorly.run
#v2
Changes in v2:
- Added to the set
Changes in v3:
- s/hdcp/hdmi/ in commit msg (Ram)
---
drivers/gpu/drm/i915/display/intel_ddi.c | 13 -
drivers/gpu/drm/i915/display/intel_ddi.h | 2 ++
.../gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.c| 11 +++
drivers/gpu/drm/i915/display/intel_hdmi.c| 16 +++-
6 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 87b8b347f682..a90ce672d2cf 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2017,12 +2017,12 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable)
{
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
intel_wakeref_t wakeref;
- enum pipe pipe = 0;
int ret = 0;
u32 tmp;
@@ -2031,18 +2031,13 @@ int intel_ddi_toggle_hdcp_signalling(struct
intel_encoder *intel_encoder,
if (WARN_ON(!wakeref))
return -ENXIO;
- if (WARN_ON(!intel_encoder->get_hw_state(intel_encoder, &pipe))) {
- ret = -EIO;
- goto out;
- }
-
- tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+ tmp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
tmp |= TRANS_DDI_HDCP_SIGNALLING;
else
tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
- I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
-out:
+ I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
+
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
}
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index 167c6579d972..5b22daf04060 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -18,6 +18,7 @@ struct intel_crtc_state;
struct intel_dp;
struct intel_dpll_hw_state;
struct intel_encoder;
+enum transcoder;
void intel_ddi_fdi_post_disable(struct intel_encoder *intel_encoder,
const struct intel_crtc_state *old_crtc_state,
@@ -45,6 +46,7 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder,
u8 voltage_swing);
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
int cnl_calc_wrpll_link(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index fdd943a17de3..8a96fedefad3 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -301,6 +301,7 @@ struct intel_hdcp_shim {
/* Enables HDCP signalling on the port */
int (*toggle_signalling)(struct intel_digital_port *intel_dig_port,
+enum transcoder cpu_transcoder,
bool enable);
/* Ensures the link is still protected */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0d59f62917ed..89501b7525a9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6083,6 +6083,7 @@ int intel_dp_hdcp_read_v_prime_part(struct
intel_digital_port *intel_dig_port,
static
int intel_dp_hdcp_toggle_signalling(struct intel_digital_port *intel_dig_port,
+ enum transcoder cpu_transcoder,
bool enable)
{
/* Not used for single stream DisplayPort setups */
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index c4394c8e10eb..f8d56d3b2ddb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -693,7 +693,7 @@ static int intel_hdcp_auth(struct intel_conne
[PATCH v3 03/12] drm/i915: WARN if HDCP signalling is enabled upon disable
From: Sean Paul
HDCP signalling should not be left on, WARN if it is
Cc: Ville Syrjälä
Cc: Daniel Vetter
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run
#v2
Changes in v2:
- Added to the set in lieu of just clearing the bit
Changes in v3:
- None
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 32ea3c7e8b62..87b8b347f682 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1998,6 +1998,8 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
val = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
val &= ~TRANS_DDI_FUNC_ENABLE;
+ WARN_ON(val & TRANS_DDI_HDCP_SIGNALLING);
+
if (INTEL_GEN(dev_priv) >= 12) {
if (!intel_dp_mst_is_master_trans(crtc_state))
val &= ~TGL_TRANS_DDI_PORT_MASK;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/12] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.
In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.
Cc: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-s...@poorly.run
#v2
Changes in v2:
- Move the toggle_signalling call into _intel_hdcp_disable so it's called from
check_work
Changes in v3:
- None
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 ++
.../drm/i915/display/intel_display_types.h| 5 ++
drivers/gpu/drm/i915/display/intel_dp.c | 2 +
drivers/gpu/drm/i915/display/intel_hdcp.c | 52 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +
5 files changed, 55 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a90ce672d2cf..4073dd96b83e 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4815,6 +4815,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
encoder = &intel_dig_port->base;
+ mutex_init(&intel_dig_port->hdcp_mutex);
+ intel_dig_port->num_hdcp_streams = 0;
+
drm_encoder_init(&dev_priv->drm, &encoder->base, &intel_ddi_funcs,
DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 8a96fedefad3..b488e8b1478e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1355,6 +1355,11 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
+ /* protects num_hdcp_streams reference count */
+ struct mutex hdcp_mutex;
+ /* the number of pipes using HDCP signalling out of this port */
+ unsigned int num_hdcp_streams;
+
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 89501b7525a9..a91f65ba35a1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7583,6 +7583,8 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder = &intel_dig_port->base;
encoder = &intel_encoder->base;
+ mutex_init(&intel_dig_port->hdcp_mutex);
+
if (drm_encoder_init(&dev_priv->drm, &intel_encoder->base,
&intel_dp_enc_funcs, DRM_MODE_ENCODER_TMDS,
"DP %c", port_name(port)))
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index fabacfb1b644..dc83d81c6df0 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -779,6 +779,19 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ /*
+* If there are other connectors on this port using HDCP, don't disable
+* it. Instead, toggle the HDCP signalling off on that particular
+* connector/pipe and exit.
+*/
+ if (intel_dig_port->num_hdcp_streams > 0) {
+ ret = hdcp->shim->toggle_signalling(intel_dig_port,
+ cpu_transcoder, false);
+ if (ret)
+ DRM_ERROR("Failed to disable HDCP signalling\n");
+ return ret;
+ }
+
hdcp->hdcp_encrypted = false;
I915_WRITE(HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
if (intel_de_wait_for_clear(dev_priv,
@@ -855,6 +868,7 @@ struct intel_connector *intel_hdcp_to_connector(struct
intel_hdcp *hdcp)
static void intel_hdcp_update_value(struct intel_connector *connector,
u64 value, bool update_property)
{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = &connector->hdcp;
WARN_ON(!mutex_is_locked(&hdcp->mutex));
@@ -862,6 +876,15 @@ static void intel_hdcp_update_value(struct intel_connector
*connector,
if (hdcp->value == value)
return;
+ WARN_ON(!mutex_is_locked(&intel_dig_port->hdcp_mutex))
[PATCH v3 04/12] drm/i915: Intercept Aksv writes in the aux hooks
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an LG monitor on my desk, I noticed it was passing
back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
auth was failing as a result. Instead of copy/pasting all of the retry
logic and delays from drm dp helpers, let's just use the helpers and hide
the aksv select as best as we can.
Reviewed-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-3-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-5-s...@poorly.run
#v2
Changes in v2:
-Remove 'generate' in intel_dp_aux_generate_xfer_flags, make arg const (Ville)
-Bundle Aksv if statement together (Ville)
-Rename 'txbuf' to 'aksv' (Ville)
Changes in v3:
-None
---
drivers/gpu/drm/i915/display/intel_dp.c | 62 -
1 file changed, 29 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4074d83b1a5f..0d59f62917ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1515,12 +1515,27 @@ intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
txbuf[3] = msg->size - 1;
}
+static u32 intel_dp_aux_xfer_flags(const struct drm_dp_aux_msg *msg)
+{
+ /*
+* If we're trying to send the HDCP Aksv, we need to set a the Aksv
+* select bit to inform the hardware to send the Aksv after our header
+* since we can't access that data from software.
+*/
+ if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_WRITE &&
+ msg->address == DP_AUX_HDCP_AKSV)
+ return DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+
+ return 0;
+}
+
static ssize_t
intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
{
struct intel_dp *intel_dp = container_of(aux, struct intel_dp, aux);
u8 txbuf[20], rxbuf[20];
size_t txsize, rxsize;
+ u32 flags = intel_dp_aux_xfer_flags(msg);
int ret;
intel_dp_aux_header(txbuf, msg);
@@ -1541,7 +1556,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
@@ -1564,7 +1579,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
return -E2BIG;
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -5904,17 +5919,9 @@ static
int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
{
- struct intel_dp *intel_dp =
enc_to_intel_dp(to_intel_encoder(&intel_dig_port->base.base));
- static const struct drm_dp_aux_msg msg = {
- .request = DP_AUX_NATIVE_WRITE,
- .address = DP_AUX_HDCP_AKSV,
- .size = DRM_HDCP_KSV_LEN,
- };
- u8 txbuf[HEADER_SIZE + DRM_HDCP_KSV_LEN] = {}, rxbuf[2], reply = 0;
+ u8 aksv[DRM_HDCP_KSV_LEN] = {};
ssize_t dpcd_ret;
- int ret;
- /* Output An first, that's easy */
dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AN,
an, DRM_HDCP_AN_LEN);
if (dpcd_ret != DRM_HDCP_AN_LEN) {
@@ -5924,29 +5931,18 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *intel_dig_port,
}
/*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So in
-* order to get it on the wire, we need to create the AUX header as if
-* we were writing the data, and then tickle the hardware to output the
-* data once the header is sent out.
+* Since Aksv is Oh-So-Secret, we can't access it in software. So we
+* send an empty buffer of the correct length through the DP helpers. On
+* the other side, in the transfer hook, we'll generate a flag based on
+* the destination address which will tickle the hardware to output the
+* Aksv on our behalf after the header is sent.
*/
- intel_dp_aux_header(txbuf, &msg);
-
- ret = intel_dp_aux_xfer(intel_dp, txbuf, HEADER_SIZE + msg.size
[PATCH v3 06/12] drm/i915: Factor out hdcp->value assignments
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-7-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-7-s...@poorly.run
#v2
Changes in v2:
-None
Changes in v3:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 67 ---
1 file changed, 46 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index f8d56d3b2ddb..798e7e1a19fc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -852,6 +852,21 @@ struct intel_connector *intel_hdcp_to_connector(struct
intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
}
+static void intel_hdcp_update_value(struct intel_connector *connector,
+ u64 value, bool update_property)
+{
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ WARN_ON(!mutex_is_locked(&hdcp->mutex));
+
+ if (hdcp->value == value)
+ return;
+
+ hdcp->value = value;
+ if (update_property)
+ schedule_work(&hdcp->prop_work);
+}
+
/* Implements Part 3 of the HDCP authorization procedure */
static int intel_hdcp_check_link(struct intel_connector *connector)
{
@@ -878,15 +893,16 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
I915_READ(HDCP_STATUS(dev_priv, cpu_transcoder,
port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
if (hdcp->shim->check_link(intel_dig_port)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
}
goto out;
}
@@ -897,16 +913,18 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
ret = _intel_hdcp_disable(connector);
if (ret) {
DRM_ERROR("Failed to disable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = _intel_hdcp_enable(connector);
if (ret) {
DRM_ERROR("Failed to enable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
@@ -1716,16 +1734,18 @@ static int intel_hdcp2_check_link(struct
intel_connector *connector)
I915_READ(HDCP2_STATUS(dev_priv, cpu_transcoder,
port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = hdcp->shim->check_2_2_link(intel_dig_port);
if (ret == HDCP_LINK_PROTECTED) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED,
+ true);
}
goto out;
}
@@ -1737,8 +1757,9 @@ static int intel_hdcp2_check_link(struct intel_connector
*connector)
DRM_DEBUG_KMS("HDCP2.2 Downstream topology change\n");
ret = hdcp2_authenticate_repeater_topology(connector);
if (!ret) {
-
[PATCH v3 10/12] drm/i915: Use ddi_update_pipe in intel_dp_mst
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-11-s...@poorly.run
#v2
Changes in v2:
-None
Changes in v3:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c| 9 +
drivers/gpu/drm/i915/display/intel_dp.h | 4
drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4073dd96b83e..43e935d3d86c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4136,9 +4136,9 @@ static void intel_ddi_update_pipe_dp(struct intel_encoder
*encoder,
intel_panel_update_backlight(encoder, crtc_state, conn_state);
}
-static void intel_ddi_update_pipe(struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
@@ -4148,7 +4148,8 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
conn_state->content_protection !=
DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
- if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+ !intel_encoder_is_mst(encoder))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
/*
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 3da166054788..0a028b58a8be 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -125,4 +125,8 @@ static inline unsigned int intel_dp_unused_lane_mask(int
lane_count)
u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state);
+
#endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index cba68c5a80fa..975d97989d3b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -774,6 +774,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
*intel_dig_port, enum
intel_encoder->compute_config = intel_dp_mst_compute_config;
intel_encoder->disable = intel_mst_disable_dp;
intel_encoder->post_disable = intel_mst_post_disable_dp;
+ intel_encoder->update_pipe = intel_ddi_update_pipe;
intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
intel_encoder->pre_enable = intel_mst_pre_enable_dp;
intel_encoder->enable = intel_mst_enable_dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/12] drm/i915: Fix sha_text population code
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being placed on the wrong half of sha_text, overlapping the leftover
ksv value
3- In the sha_leftovers == 2 case, we need to manually terminate the
byte stream with 0x80 since the hardware doesn't have enough room to
add it after writing M0
The upside is that all of the HDCP supported HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-s...@poorly.run
#v2
Changes in v2:
-None
Changes in v3:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 25 +--
include/drm/drm_hdcp.h| 3 +++
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 0fdbd39f6641..eaab9008feef 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -335,8 +335,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Fill up the empty slots in sha_text and write it out */
sha_empty = sizeof(sha_text) - sha_leftovers;
- for (j = 0; j < sha_empty; j++)
- sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
+ for (j = 0; j < sha_empty; j++) {
+ u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) *
8);
+ sha_text |= ksv[j] << off;
+ }
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
@@ -426,7 +428,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
} else if (sha_leftovers == 2) {
/* Write 32 bits of text */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24 | bstatus[1] << 16;
+ sha_text |= bstatus[0] << 8 | bstatus[1];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
@@ -440,16 +442,27 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
return ret;
sha_idx += sizeof(sha_text);
}
+
+ /*
+* Terminate the SHA-1 stream by hand. For the other leftover
+* cases this is appended by the hardware.
+*/
+ I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
+ sha_text = DRM_HDCP_SHA1_TERMINATOR << 24;
+ ret = intel_write_sha_text(dev_priv, sha_text);
+ if (ret < 0)
+ return ret;
+ sha_idx += sizeof(sha_text);
} else if (sha_leftovers == 3) {
- /* Write 32 bits of text */
+ /* Write 32 bits of text (filled from LSB) */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24;
+ sha_text |= bstatus[0];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
sha_idx += sizeof(sha_text);
- /* Write 8 bits of text, 24 bits of M0 */
+ /* Write 8 bits of text (filled from LSB), 24 bits of M0 */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_8);
ret = intel_write_sha_text(dev_priv, bstatus[1]);
if (ret < 0)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 06a11202a097..20498c822204 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -29,6 +29,9 @@
/* Slave address for the HDCP registers in the receiver */
#define DRM_HDCP_DDC_ADDR 0x3A
+/* Value to use at the end of the SHA-1 bytestream used for repeaters */
+#define DRM_HDCP_SHA1_TERMINATOR 0x80
+
/* HDCP register offsets for HDMI/DVI devices */
#define DRM_HDCP_DDC_BKSV 0x00
#define DRM_HDCP_DDC_RI_PRIME 0x08
--
Sean Paul, Software Engineer,
[PATCH v3 12/12] drm/i915: Add HDCP 1.4 support for MST connectors
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
#v2
Changes in v2:
- Toggle HDCP from encoder disable/enable
- Don't disable HDCP on MST connector destroy, leave that for encoder
disable, just ensure the check_work routine isn't running any longer
Changes in v3:
- Place the shim in the new intel_dp_hdcp.c file (Ville)
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 78 +++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 14
2 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 0b6d90980e90..a93ad675e7bb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -11,6 +11,7 @@
#include
#include "intel_display_types.h"
+#include "intel_ddi.h"
#include "intel_dp.h"
#include "intel_hdcp.h"
@@ -585,6 +586,78 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.protocol = HDCP_PROTOCOL_DP,
};
+static int
+intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port *intel_dig_port,
+ enum transcoder cpu_transcoder,
+ bool enable)
+{
+ int ret;
+
+ ret = intel_ddi_toggle_hdcp_signalling(&intel_dig_port->base,
+ cpu_transcoder, enable);
+ if (ret)
+ DRM_DEBUG_KMS("%s HDCP signalling failed (%d)\n",
+ enable ? "Enable" : "Disable", ret);
+ return ret;
+}
+
+static
+int intel_dp_mst_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
+void *buf, size_t size)
+{
+ return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_read_msg(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, void *buf, size_t size)
+{
+ return -EOPNOTSUPP;
+}
+
+static int
+intel_dp_mst_hdcp2_config_stream_type(struct intel_digital_port
*intel_dig_port,
+ bool is_repeater, u8 content_type)
+{
+ return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_check_link(struct intel_digital_port *intel_dig_port)
+{
+ return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_capable(struct intel_digital_port *intel_dig_port,
+ bool *capable)
+{
+ *capable = false;
+ return 0;
+}
+
+static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
+ .write_an_aksv = intel_dp_hdcp_write_an_aksv,
+ .read_bksv = intel_dp_hdcp_read_bksv,
+ .read_bstatus = intel_dp_hdcp_read_bstatus,
+ .repeater_present = intel_dp_hdcp_repeater_present,
+ .read_ri_prime = intel_dp_hdcp_read_ri_prime,
+ .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
+ .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
+ .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
+ .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
+ .check_link = intel_dp_hdcp_check_link,
+ .hdcp_capable = intel_dp_hdcp_capable,
+
+ .write_2_2_msg = intel_dp_mst_hdcp2_write_msg,
+ .read_2_2_msg = intel_dp_mst_hdcp2_read_msg,
+ .config_stream_type = intel_dp_mst_hdcp2_config_stream_type,
+ .check_2_2_link = intel_dp_mst_hdcp2_check_link,
+ .hdcp_2_2_capable = intel_dp_mst_hdcp2_capable,
+
+ .protocol = HDCP_PROTOCOL_DP,
+};
+
int intel_dp_init_hdcp(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector)
{
@@ -597,7 +670,10 @@ int intel_dp_init_hdcp(struct intel_digital_port
*intel_dig_port,
if (!is_hdcp_supported(dev_priv, port))
return 0;
- if (!intel_dp_is_edp(intel_dp))
+ if (!intel_encoder_is_mst(intel_encoder))
+ return intel_hdcp_init(intel_connector,
+ &intel_dp_mst_hdcp_shim);
+ else if (!intel_dp_is_edp(intel_dp))
return intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 975d97989d3b..00c2032c71ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -36,6 +36,7 @@
#include "intel_dp.h"
#include "intel_dp_mst.h"
#include "intel_dpio_phy.h"
+#include "intel_hdcp.h"
static int intel_dp_mst_compute_link_config(struct intel_encoder *encoder,
struct intel_crtc_stat
[PATCH v3 11/12] drm/i915: Factor out HDCP shim functions from dp for use by dp_mst
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-12-s...@poorly.run
#v2
Changes in v2:
-None
Changes in v3:
-Created intel_dp_hdcp.c for the shared functions to live (Ville)
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 580 +-
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 604 +++
4 files changed, 612 insertions(+), 576 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3c88d7d8c764..d4ce488f58e9 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -218,6 +218,7 @@ i915-y += \
display/intel_ddi.o \
display/intel_dp.o \
display/intel_dp_aux_backlight.o \
+ display/intel_dp_hdcp.o \
display/intel_dp_link_training.o \
display/intel_dp_mst.o \
display/intel_dsi.o \
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a91f65ba35a1..6cc83af60604 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5903,576 +5903,6 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
edp_panel_vdd_off_sync(intel_dp);
}
-static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp, int timeout)
-{
- long ret;
-
-#define C (hdcp->cp_irq_count_cached != atomic_read(&hdcp->cp_irq_count))
- ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
- msecs_to_jiffies(timeout));
-
- if (!ret)
- DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
-}
-
-static
-int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
- u8 *an)
-{
- u8 aksv[DRM_HDCP_KSV_LEN] = {};
- ssize_t dpcd_ret;
-
- dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AN,
-an, DRM_HDCP_AN_LEN);
- if (dpcd_ret != DRM_HDCP_AN_LEN) {
- DRM_DEBUG_KMS("Failed to write An over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
-
- /*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So we
-* send an empty buffer of the correct length through the DP helpers. On
-* the other side, in the transfer hook, we'll generate a flag based on
-* the destination address which will tickle the hardware to output the
-* Aksv on our behalf after the header is sent.
-*/
- dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AKSV,
-aksv, DRM_HDCP_KSV_LEN);
- if (dpcd_ret != DRM_HDCP_KSV_LEN) {
- DRM_DEBUG_KMS("Failed to write Aksv over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
- u8 *bksv)
-{
- ssize_t ret;
- ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BKSV, bksv,
- DRM_HDCP_KSV_LEN);
- if (ret != DRM_HDCP_KSV_LEN) {
- DRM_DEBUG_KMS("Read Bksv from DP/AUX failed (%zd)\n", ret);
- return ret >= 0 ? -EIO : ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bstatus(struct intel_digital_port
*intel_dig_port,
- u8 *bstatus)
-{
- ssize_t ret;
- /*
-* For some reason the HDMI and DP HDCP specs call this register
-* definition by different names. In the HDMI spec, it's called BSTATUS,
-* but in DP it's called BINFO.
-*/
- ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BINFO,
- bstatus, DRM_HDCP_BSTATUS_LEN);
- if (ret != DRM_HDCP_BSTATUS_LEN) {
- DRM_DEBUG_KMS("Read bstatus from DP/AUX failed (%zd)\n", ret);
- return ret >= 0 ? -EIO : ret;
- }
- return 0;
-}
-
-static
-int intel_dp_hdcp_read_bcaps(struct intel_digital_port *intel_dig_port,
-u8 *bcaps)
-{
- ssize_t ret;
-
- ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BCAPS,
- bcaps, 1);
- if (ret != 1) {
- DRM_DEBUG_KMS("Read bcaps from DP/AUX failed (%zd)\n", ret);
- r
[PATCH v3 07/12] drm/i915: Protect workers against disappearing connectors
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't do a synchronous wait since it needs
to take connection_mutex which could cause deadlock. Instead, we'll take
a reference on the connector when scheduling prop_work and give it up
once we're done.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-s...@poorly.run
#v2
Changes in v2:
- Added to the set
Changes in v3:
- Change the WARN_ON condition in intel_hdcp_cleanup to allow for
initializing connectors as well
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 43 ---
1 file changed, 38 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 798e7e1a19fc..fabacfb1b644 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -863,8 +863,10 @@ static void intel_hdcp_update_value(struct intel_connector
*connector,
return;
hdcp->value = value;
- if (update_property)
+ if (update_property) {
+ drm_connector_get(&connector->base);
schedule_work(&hdcp->prop_work);
+ }
}
/* Implements Part 3 of the HDCP authorization procedure */
@@ -954,6 +956,8 @@ static void intel_hdcp_prop_work(struct work_struct *work)
mutex_unlock(&hdcp->mutex);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ drm_connector_put(&connector->base);
}
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
@@ -1802,6 +1806,9 @@ static void intel_hdcp_check_work(struct work_struct
*work)
check_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
+ if (drm_connector_is_unregistered(&connector->base))
+ return;
+
if (!intel_hdcp2_check_link(connector))
schedule_delayed_work(&hdcp->check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
@@ -2076,12 +2083,38 @@ void intel_hdcp_component_fini(struct drm_i915_private
*dev_priv)
void intel_hdcp_cleanup(struct intel_connector *connector)
{
- if (!connector->hdcp.shim)
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ if (!hdcp->shim)
return;
- mutex_lock(&connector->hdcp.mutex);
- kfree(connector->hdcp.port_data.streams);
- mutex_unlock(&connector->hdcp.mutex);
+ /*
+* If the connector is registered, it's possible userspace could kick
+* off another HDCP enable, which would re-spawn the workers.
+*/
+ WARN_ON(connector->base.registration_state == DRM_CONNECTOR_REGISTERED);
+
+ /*
+* Now that the connector is not registered, check_work won't be run,
+* but cancel any outstanding instances of it
+*/
+ cancel_delayed_work_sync(&hdcp->check_work);
+
+ /*
+* We don't cancel prop_work in the same way as check_work since it
+* requires connection_mutex which could be held while calling this
+* function. Instead, we rely on the connector references grabbed before
+* scheduling prop_work to ensure the connector is alive when prop_work
+* is run. So if we're in the destroy path (which is where this
+* function should be called), we're "guaranteed" that prop_work is not
+* active (tl;dr This Should Never Happen).
+*/
+ WARN_ON(work_pending(&hdcp->prop_work));
+
+ mutex_lock(&hdcp->mutex);
+ kfree(hdcp->port_data.streams);
+ hdcp->shim = NULL;
+ mutex_unlock(&hdcp->mutex);
}
void intel_hdcp_atomic_check(struct drm_connector *connector,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/12] drm/i915: Support DP MST in enc_to_dig_port() function
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-10-s...@poorly.run
#v2
Changes in v2:
-None
Changes in v3:
-None
---
.../drm/i915/display/intel_display_types.h| 21 ---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b488e8b1478e..d7f4897a1eb9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1460,6 +1460,18 @@ static inline bool intel_encoder_is_dig_port(struct
intel_encoder *encoder)
}
}
+static inline bool intel_encoder_is_mst(struct intel_encoder *encoder)
+{
+ return encoder->type == INTEL_OUTPUT_DP_MST;
+}
+
+static inline struct intel_dp_mst_encoder *
+enc_to_mst(struct intel_encoder *encoder)
+{
+ return container_of(&encoder->base, struct intel_dp_mst_encoder,
+ base.base);
+}
+
static inline struct intel_digital_port *
enc_to_dig_port(struct intel_encoder *encoder)
{
@@ -1468,6 +1480,8 @@ enc_to_dig_port(struct intel_encoder *encoder)
if (intel_encoder_is_dig_port(intel_encoder))
return container_of(&encoder->base, struct intel_digital_port,
base.base);
+ else if (intel_encoder_is_mst(intel_encoder))
+ return enc_to_mst(encoder)->primary;
else
return NULL;
}
@@ -1478,13 +1492,6 @@ conn_to_dig_port(struct intel_connector *connector)
return enc_to_dig_port(intel_attached_encoder(connector));
}
-static inline struct intel_dp_mst_encoder *
-enc_to_mst(struct intel_encoder *encoder)
-{
- return container_of(&encoder->base, struct intel_dp_mst_encoder,
- base.base);
-}
-
static inline struct intel_dp *enc_to_intel_dp(struct intel_encoder *encoder)
{
return &enc_to_dig_port(encoder)->dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] video: fbdev: controlfb: add COMPILE_TEST support
Hi Bartlomiej
On Thu, Jan 16, 2020 at 03:08:57PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to controlfb driver for better compile
> testing coverage.
This is not a nice patch to add COMPILE_TEST support :-(
But I see why you do it.
I already spent too much time being side-tracked by this, but here are
some comments to consider.
With the comments considered:
Acked-by: Sam Ravnborg
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/video/fbdev/Kconfig | 2 +-
> drivers/video/fbdev/controlfb.c | 21 +++--
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index aa9541bf964b..91c872457863 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -472,7 +472,7 @@ config FB_OF
>
> config FB_CONTROL
> bool "Apple \"control\" display support"
> - depends on (FB = y) && PPC_PMAC && PPC32
> + depends on (FB = y) && ((PPC_PMAC && PPC32) || COMPILE_TEST)
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
> index bd0f61d8bdb5..87cd817ad4c6 100644
> --- a/drivers/video/fbdev/controlfb.c
> +++ b/drivers/video/fbdev/controlfb.c
> @@ -47,12 +47,25 @@
> #include
> #include
> #include
> +#ifdef CONFIG_PPC_PMAC
> #include
> #include
> +#endif
>
> #include "macmodes.h"
> #include "controlfb.h"
>
> +#ifndef CONFIG_PPC_PMAC
> +#undef in_8
> +#undef out_8
> +#undef in_le32
> +#undef out_le32
> +#define in_8(addr) 0
> +#define out_8(addr, val)
> +#define in_le32(addr)0
> +#define out_le32(addr, val)
> +#endif
> +
> struct fb_par_control {
> int vmode, cmode;
> int xres, yres;
> @@ -278,7 +291,9 @@ static int controlfb_mmap(struct fb_info *info,
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> } else {
> /* framebuffer */
> +#ifdef CONFIG_PPC_PMAC
> vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
> +#endif
Add:
#define pgprot_cached_wthru(x) 0
in the CONFIG_PPC_PMAC block?
> }
>
> return vm_iomap_memory(vma, start, len);
> @@ -582,13 +597,14 @@ static void __init find_vram_size(struct
> fb_info_control *p)
>
> out_8(&p->frame_buffer[0x60], 0xb3);
> out_8(&p->frame_buffer[0x61], 0x71);
> +#ifdef CONFIG_PPC_PMAC
> asm volatile("eieio; dcbf 0,%0" : : "r" (&p->frame_buffer[0x60])
> : "memory" );
> mb();
> asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0x60])
> : "memory" );
> mb();
> -
> +#endif
The inline asm block could be written as:
static void invalid_vram_cache(void * addr)
{
eieio();
dcbf(addr);
mb;
eieio();
dcbi(addr);
mb();
}
And then this inline function could be in the CONFIG_PPC_PMAC block -
and a dummy in the else part.
The function name is just my best guess what the assembler does.
> bank2 = (in_8(&p->frame_buffer[0x60]) == 0xb3)
> && (in_8(&p->frame_buffer[0x61]) == 0x71);
>
> @@ -601,13 +617,14 @@ static void __init find_vram_size(struct
> fb_info_control *p)
>
> out_8(&p->frame_buffer[0], 0x5a);
> out_8(&p->frame_buffer[1], 0xc7);
> +#ifdef CONFIG_PPC_PMAC
> asm volatile("eieio; dcbf 0,%0" : : "r" (&p->frame_buffer[0])
> : "memory" );
> mb();
> asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0])
> : "memory" );
> mb();
> -
> +#endif
Same here.
> bank1 = (in_8(&p->frame_buffer[0]) == 0x5a)
> && (in_8(&p->frame_buffer[1]) == 0xc7);
>
> --
> 2.24.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
[PATCH v3 02/12] drm/i915: Clear the repeater bit on HDCP disable
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-s...@poorly.run
#v2
Changes in v2:
-Added to the set
Changes in v3:
-None
I had previously agreed that clearing the rep_ctl bits on enable would
also be a good idea. However when I committed that idea to code, it
didn't look right. So let's rely on enables and disables being paired
and everything outside of that will be considered a bug
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index eaab9008feef..c4394c8e10eb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -773,6 +773,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
enum port port = intel_dig_port->base.port;
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+ u32 repeater_ctl;
int ret;
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
@@ -787,6 +788,10 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
return -ETIMEDOUT;
}
+ repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
+ port);
+ I915_WRITE(HDCP_REP_CTL, I915_READ(HDCP_REP_CTL) & ~repeater_ctl);
+
ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
if (ret) {
DRM_ERROR("Failed to disable HDCP signalling\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/12] drm/i915: Add support for HDCP 1.4 over MST connectors
From: Sean Paul Hey all, Here's v3, which addresses all review comments in v2. Sean Sean Paul (12): drm/i915: Fix sha_text population code drm/i915: Clear the repeater bit on HDCP disable drm/i915: WARN if HDCP signalling is enabled upon disable drm/i915: Intercept Aksv writes in the aux hooks drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling drm/i915: Factor out hdcp->value assignments drm/i915: Protect workers against disappearing connectors drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it drm/i915: Support DP MST in enc_to_dig_port() function drm/i915: Use ddi_update_pipe in intel_dp_mst drm/i915: Factor out HDCP shim functions from dp for use by dp_mst drm/i915: Add HDCP 1.4 support for MST connectors drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 27 +- drivers/gpu/drm/i915/display/intel_ddi.h | 2 + .../drm/i915/display/intel_display_types.h| 27 +- drivers/gpu/drm/i915/display/intel_dp.c | 619 +--- drivers/gpu/drm/i915/display/intel_dp.h | 7 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 680 ++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 + drivers/gpu/drm/i915/display/intel_hdcp.c | 195 +++-- drivers/gpu/drm/i915/display/intel_hdmi.c | 18 +- include/drm/drm_hdcp.h| 3 + 11 files changed, 932 insertions(+), 662 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #9 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- On Fri, Jan 17, 2020 at 06:45:28PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > screenshot : https://i.ibb.co/PrHj3hV/tombraider.jpg This seems to be from "shadow of the tomb raider" which I don't "own". Do you "own" "rise of the tomb raider", the previous tomb raider game (which I "own")? -- 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: [Bug 206231] R9 280X low performance with all games
On Fri, Jan 17, 2020 at 06:45:28PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > screenshot : https://i.ibb.co/PrHj3hV/tombraider.jpg This seems to be from "shadow of the tomb raider" which I don't "own". Do you "own" "rise of the tomb raider", the previous tomb raider game (which I "own")? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] video: fbdev: controlfb: fix sparse warning about using incorrect type
Hi Bartlomiej
On Thu, Jan 16, 2020 at 03:08:55PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Force le32_to_cpup() argument to be of proper type (const __le32 *).
>
> Also add missing inline keyword to control_par_to_var() definition
> (to match function prototype).
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/video/fbdev/controlfb.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
> index 38b61cdb5ca4..d7e53520a24c 100644
> --- a/drivers/video/fbdev/controlfb.c
> +++ b/drivers/video/fbdev/controlfb.c
> @@ -313,7 +313,7 @@ static int controlfb_blank(int blank_mode, struct fb_info
> *info)
> container_of(info, struct fb_info_control, info);
> unsigned ctrl;
>
> - ctrl = le32_to_cpup(CNTRL_REG(p,ctrl));
> + ctrl = le32_to_cpup((const __force __le32 *)CNTRL_REG(p, ctrl));
Only judging from the other code in the same driver,
I think a better fix would be to use:
ctrl = in_le32(CNTRL_REG(p,ctrl));
?
Sam
> if (blank_mode > 0)
> switch (blank_mode) {
> case FB_BLANK_VSYNC_SUSPEND:
> @@ -952,7 +952,8 @@ static int control_var_to_par(struct fb_var_screeninfo
> *var,
> * Convert hardware data in par to an fb_var_screeninfo
> */
>
> -static void control_par_to_var(struct fb_par_control *par, struct
> fb_var_screeninfo *var)
> +static inline void control_par_to_var(struct fb_par_control *par,
> + struct fb_var_screeninfo *var)
> {
> struct control_regints *rv;
>
> --
> 2.24.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 1/2] video: fbdev: wm8505fb: fix sparse warnings about using incorrect types
On Thu, Jan 16, 2020 at 03:54:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
>
> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
> pointer") for details. ]
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Sam Ravnborg
> ---
> drivers/video/fbdev/wm8505fb.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: b/drivers/video/fbdev/wm8505fb.c
> ===
> --- a/drivers/video/fbdev/wm8505fb.c
> +++ b/drivers/video/fbdev/wm8505fb.c
> @@ -339,7 +339,7 @@ static int wm8505fb_probe(struct platfor
>
> fbi->fb.fix.smem_start = fb_mem_phys;
> fbi->fb.fix.smem_len= fb_mem_len;
> - fbi->fb.screen_base = fb_mem_virt;
> + fbi->fb.screen_buffer = fb_mem_virt;
> fbi->fb.screen_size = fb_mem_len;
>
> fbi->contrast = 0x10;
> ___
> 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 1/2] video: fbdev: wm8505fb: fix sparse warnings about using incorrect types
On Thu, Jan 16, 2020 at 03:56:50PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
>
> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
> pointer") for details. ]
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Sam Ravnborg
> ---
> Resend with Tony & linux-arm ML added to Cc:.
>
> drivers/video/fbdev/wm8505fb.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: b/drivers/video/fbdev/wm8505fb.c
> ===
> --- a/drivers/video/fbdev/wm8505fb.c
> +++ b/drivers/video/fbdev/wm8505fb.c
> @@ -339,7 +339,7 @@ static int wm8505fb_probe(struct platfor
>
> fbi->fb.fix.smem_start = fb_mem_phys;
> fbi->fb.fix.smem_len= fb_mem_len;
> - fbi->fb.screen_base = fb_mem_virt;
> + fbi->fb.screen_buffer = fb_mem_virt;
> fbi->fb.screen_size = fb_mem_len;
>
> fbi->contrast = 0x10;
> ___
> 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] video: fbdev: wm8505fb: add COMPILE_TEST support
On Thu, Jan 16, 2020 at 03:58:08PM +0100, Bartlomiej Zolnierkiewicz wrote: > Add COMPILE_TEST support to wm8505fb driver for better compile > testing coverage. > > Signed-off-by: Bartlomiej Zolnierkiewicz Acked-by: Sam Ravnborg > --- > drivers/video/fbdev/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: b/drivers/video/fbdev/Kconfig > === > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -1639,7 +1639,7 @@ config FB_VT8500 > > config FB_WM8505 > bool "Wondermedia WM8xxx-series frame buffer support" > - depends on (FB = y) && ARM && ARCH_VT8500 > + depends on (FB = y) && HAS_IOMEM && (ARCH_VT8500 || COMPILE_TEST) > select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS) > select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS) > select FB_SYS_IMAGEBLIT > ___ > 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] video: fbdev: w100fb: add COMPILE_TEST support
On Thu, Jan 16, 2020 at 03:53:58PM +0100, Bartlomiej Zolnierkiewicz wrote: > Add COMPILE_TEST support to w100fb driver for better compile > testing coverage. > > Signed-off-by: Bartlomiej Zolnierkiewicz Acked-by: Sam Ravnborg > --- > drivers/video/fbdev/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: b/drivers/video/fbdev/Kconfig > === > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -1827,7 +1827,7 @@ config FB_FSL_DIU > > config FB_W100 > tristate "W100 frame buffer support" > - depends on FB && ARCH_PXA > + depends on FB && HAS_IOMEM && (ARCH_PXA || COMPILE_TEST) > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > select FB_CFB_IMAGEBLIT > ___ > 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 1/2] video: fbdev: w100fb: fix sparse warnings
On Thu, Jan 16, 2020 at 03:53:20PM +0100, Bartlomiej Zolnierkiewicz wrote:
> * Add missing __iomem annotations where needed.
> * Make w100fb_probe() static.
> * Return NULL pointer (instead of using plain integer) in
> w100_get_xtal_tabl().
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Sam Ravnborg
> ---
> drivers/video/fbdev/w100fb.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> Index: b/drivers/video/fbdev/w100fb.c
> ===
> --- a/drivers/video/fbdev/w100fb.c
> +++ b/drivers/video/fbdev/w100fb.c
> @@ -61,9 +61,9 @@ struct w100_pll_info *w100_get_xtal_tabl
> #define BITS_PER_PIXEL16
>
> /* Remapped addresses for base cfg, memmapped regs and the frame buffer
> itself */
> -static void *remapped_base;
> -static void *remapped_regs;
> -static void *remapped_fbuf;
> +static void __iomem *remapped_base;
> +static void __iomem *remapped_regs;
> +static void __iomem *remapped_fbuf;
>
> #define REMAPPED_FB_LEN 0x15
>
> @@ -635,7 +635,7 @@ static int w100fb_resume(struct platform
> #endif
>
>
> -int w100fb_probe(struct platform_device *pdev)
> +static int w100fb_probe(struct platform_device *pdev)
> {
> int err = -EIO;
> struct w100fb_mach_info *inf;
> @@ -807,10 +807,11 @@ static int w100fb_remove(struct platform
>
> static void w100_soft_reset(void)
> {
> - u16 val = readw((u16 *) remapped_base + cfgSTATUS);
> - writew(val | 0x08, (u16 *) remapped_base + cfgSTATUS);
> + u16 val = readw((u16 __iomem *)remapped_base + cfgSTATUS);
> +
> + writew(val | 0x08, (u16 __iomem *)remapped_base + cfgSTATUS);
> udelay(100);
> - writew(0x00, (u16 *) remapped_base + cfgSTATUS);
> + writew(0x00, (u16 __iomem *)remapped_base + cfgSTATUS);
> udelay(100);
> }
>
> @@ -1022,7 +1023,8 @@ struct w100_pll_info *w100_get_xtal_tabl
> return pll_entry->pll_table;
> pll_entry++;
> } while (pll_entry->xtal_freq);
> - return 0;
> +
> + return NULL;
> }
>
>
> ___
> 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] video: fbdev: arcfb: add COMPILE_TEST support
On Thu, Jan 16, 2020 at 03:49:07PM +0100, Bartlomiej Zolnierkiewicz wrote: > Add COMPILE_TEST support to arcfb driver for better compile > testing coverage. > > Signed-off-by: Bartlomiej Zolnierkiewicz Acked-by: Sam Ravnborg > --- > drivers/video/fbdev/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: b/drivers/video/fbdev/Kconfig > === > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -435,7 +435,7 @@ config FB_FM2 > > config FB_ARC > tristate "Arc Monochrome LCD board support" > - depends on FB && X86 > + depends on FB && (X86 || COMPILE_TEST) > select FB_SYS_FILLRECT > select FB_SYS_COPYAREA > select FB_SYS_IMAGEBLIT > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] Add support for Pine64 PineTab
On Fri, Jan 17, 2020 at 07:50:12PM +0100, Sam Ravnborg wrote: > Hi Icenowy > > On Thu, Jan 16, 2020 at 11:36:31AM +0800, Icenowy Zheng wrote: > > This patchset tries to add support for the PineTab tablet from Pine64. > > > > As it uses a specific MIPI-DSI panel, the support of the panel should be > > introduced first, with its DT binding. > > > > Then a device tree is added. Compared to v1 of the patchset, the > > accelerometer support is temporarily removed because a DT binding is > > lacked (although a proper driver exists). > > > > Icenowy Zheng (5): > > dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd > > dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel > > drm/panel: Add Feixin K101 IM2BA02 panel > > dt-bindings: arm: sunxi: add binding for PineTab tablet > > arm64: dts: allwinner: a64: add support for PineTab > > Thanks for the updates. > I have applied the first three patches to drm-misc-next. > The remaining two patches shall most likely go in via another tree. queued the last two for 5.7, thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/2] drm/modes: Apply video parameters with only reflect option
On Fri, Jan 17, 2020 at 04:34:27PM +0100, Stephan Gerhold wrote: > At the moment, video mode parameters like video=540x960,reflect_x, > (without rotation set) are not taken into account when applying the > mode in drm_client_modeset.c. > > One of the reasons for this is that the calculation that > combines the panel_orientation with cmdline->rotation_reflection > does not handle the case when cmdline->rotation_reflection does > not have any rotation set. > (i.e. cmdline->rotation_reflection & DRM_MODE_ROTATE_MASK == 0) > > However, we really should not generate such a value in the first place. > Rotation values should have exactly one rotation angle set > (DRM_MODE_ROTATE_0 for "no rotation"). > > This patch set changes the command line parser to make sure that we generate > only valid rotation values (defaulting to DRM_MODE_ROTATE_0). > > Finally it allows DRM_MODE_ROTATE_0 when applying the rotation from > the video mode parameters to make parameters without rotation work correctly. For both, Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] Add support for Pine64 PineTab
Hi Icenowy On Thu, Jan 16, 2020 at 11:36:31AM +0800, Icenowy Zheng wrote: > This patchset tries to add support for the PineTab tablet from Pine64. > > As it uses a specific MIPI-DSI panel, the support of the panel should be > introduced first, with its DT binding. > > Then a device tree is added. Compared to v1 of the patchset, the > accelerometer support is temporarily removed because a DT binding is > lacked (although a proper driver exists). > > Icenowy Zheng (5): > dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd > dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel > drm/panel: Add Feixin K101 IM2BA02 panel > dt-bindings: arm: sunxi: add binding for PineTab tablet > arm64: dts: allwinner: a64: add support for PineTab Thanks for the updates. I have applied the first three patches to drm-misc-next. The remaining two patches shall most likely go in via another tree. Sam > > .../devicetree/bindings/arm/sunxi.yaml| 5 + > .../display/panel/feixin,k101-im2ba02.yaml| 55 ++ > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > MAINTAINERS | 6 + > arch/arm64/boot/dts/allwinner/Makefile| 1 + > .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 460 +++ > drivers/gpu/drm/panel/Kconfig | 9 + > drivers/gpu/drm/panel/Makefile| 1 + > .../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 526 ++ > 9 files changed, 1065 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts > create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c > > -- > 2.23.0 > > ___ > 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
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #8 from kentosama (kentos...@whiteninjastudio.com) --- (In reply to Sylvain BERTRAND from comment #6) > Owner and user of tahiti parts on amdgpu with a state of the art gfx stack > poping in. > > I own "rise of the tomb raider" which gnu/linux port is vulkan only, and > vulkan > is only available with the "amdgpu" kernel module (as far as I know). > > I have not bought "shadow of the tomb raider", which is vulkan only too (the > port was coded by the same company). > > I did clear "rise of the tomb raider" years ago, I cannot play it anymore > because the driver seems to miscompile some shaders and does gpu vm faults > (from my save file). I did open a bug. > > I heard 'southern islands' parts (tahiti...) do suffer from a critical "mip > mapping" slowdown bug. That could explain the slugginesh of those hardware > parts in 3d intense games (I did almost stop playing "rise of the tomb > raider" > because the 3d rendering was unpleasantly not smooth enough). > > If you want, we can try to compare our benchmarks? Sure, but I only have the first Tomb Raider, the one released in 2013 it seems to me. Do you know a command to record the game framerate log ? -- 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 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #7 from kentosama (kentos...@whiteninjastudio.com) --- I noticed something strange. When I do the Tomb Raider benchmark, the GPU usage is 100% and I hear the fans running at full speed after a few seconds. The bench gives a result of a minimum of 37 fps, a maximum 70fps and an average of 55.3fps with the graphic parameters on ultimate. There is something wrong, because during the "slum" sequence, I get a 10/15 fps framerate with a ridiculous GPU load. screenshot : https://i.ibb.co/PrHj3hV/tombraider.jpg -- 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 v2] drm/msm: Add syncobj support.
On Fri, Jan 17, 2020 at 7:17 PM Jordan Crouse wrote:
>
> On Fri, Jan 17, 2020 at 12:04:17AM +0100, Bas Nieuwenhuizen wrote:
> > This
> >
> > 1) Enables core DRM syncobj support.
> > 2) Adds options to the submission ioctl to wait/signal syncobjs.
> >
> > Just like the wait fence fd, this does inline waits. Using the
> > scheduler would be nice but I believe it is out of scope for
> > this work.
> >
> > Support for timeline syncobjs is implemented and the interface
> > is ready for it, but I'm not enabling it yet until there is
> > some code for turnip to use it.
> >
> > The reset is mostly in there because in the presence of waiting
> > and signalling the same semaphores, resetting them after
> > signalling can become very annoying.
> >
> > v2:
> > - Fixed style issues
> > - Removed a cleanup issue in a failure case
> > - Moved to a copy_from_user per syncobj
>
> A few nits, but nothing serious. This is looking good, thanks for the quick
> turn around.
>
> > Signed-off-by: Bas Nieuwenhuizen
> > ---
> > drivers/gpu/drm/msm/msm_drv.c| 6 +-
> > drivers/gpu/drm/msm/msm_gem_submit.c | 236 ++-
> > include/uapi/drm/msm_drm.h | 24 ++-
> > 3 files changed, 262 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index c84f0a8b3f2c..5246b41798df 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -37,9 +37,10 @@
> > * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
> > * GEM object's debug name
> > * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> > + * - 1.6.0 - Syncobj support
> > */
> > #define MSM_VERSION_MAJOR1
> > -#define MSM_VERSION_MINOR5
> > +#define MSM_VERSION_MINOR6
> > #define MSM_VERSION_PATCHLEVEL 0
> >
> > static const struct drm_mode_config_funcs mode_config_funcs = {
> > @@ -988,7 +989,8 @@ static struct drm_driver msm_driver = {
> > .driver_features= DRIVER_GEM |
> > DRIVER_RENDER |
> > DRIVER_ATOMIC |
> > - DRIVER_MODESET,
> > + DRIVER_MODESET |
> > + DRIVER_SYNCOBJ,
> > .open = msm_open,
> > .postclose = msm_postclose,
> > .lastclose = drm_fb_helper_lastclose,
> > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > index be5327af16fa..6c7f95fc5cfd 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > @@ -8,7 +8,9 @@
> > #include
> > #include
> >
> > +#include
> > #include
> > +#include
> >
> > #include "msm_drv.h"
> > #include "msm_gpu.h"
> > @@ -394,6 +396,191 @@ static void submit_cleanup(struct msm_gem_submit
> > *submit)
> > ww_acquire_fini(&submit->ticket);
> > }
> >
> > +
> > +struct msm_submit_post_dep {
> > + struct drm_syncobj *syncobj;
> > + uint64_t point;
> > + struct dma_fence_chain *chain;
> > +};
> > +
> > +static int msm_wait_deps(struct drm_device *dev,
> > + struct drm_file *file,
> > + uint64_t in_syncobjs_addr,
> > + uint32_t nr_in_syncobjs,
> > + uint32_t syncobj_stride,
> > + struct msm_ringbuffer *ring,
> > + struct drm_syncobj ***syncobjs)
> > +{
> > + struct drm_msm_gem_submit_syncobj syncobj_desc = {0};
> > + int ret = 0;
> > + uint32_t i, j;
> > +
> > + *syncobjs = kcalloc(nr_in_syncobjs, sizeof(**syncobjs),
> > + GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
>
> Perfect - I think this will do everything we want - protect us against OOM
> death
> but also not introduce artificial constraints on object counts.
>
> > + if (!syncobjs) {
>
> You should be able to just return -ENOMEM here.
>
> > + ret = -ENOMEM;
> > + goto out_syncobjs;
> > + }
>
> > +
> > + for (i = 0; i < nr_in_syncobjs; ++i) {
> > + uint64_t address = in_syncobjs_addr + i * syncobj_stride;
> > + struct dma_fence *fence;
> > +
> > + if (copy_from_user(&syncobj_desc,
> > +u64_to_user_ptr(address),
> > +min(syncobj_stride,
> > sizeof(syncobj_desc {
> > + ret = -EFAULT;
> > + goto out_syncobjs;
>
> You can just use break here.
>
> > + }
> > +
> > + if (syncobj_desc.point &&
> > + !drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE)) {
> > + ret = -EOPNOTSUPP;
> > + break;
> > + }
> > +
> > + if (syncobj_desc.flags & ~MSM_SUBMIT_SYNCOBJ_FLAGS) {
> > + ret = -EINVAL;
> > +
Re: [PATCH v9 0/5] add driver for "boe, tv101wum-nl6", "boe, tv101wum-n53", "auo, kd101n80-45na" and "auo, b101uan08.3" panels
Hi Jitao. Thanks for your perseverance on this. With the minor issue on the binding file resolved everything is now fine and patches are all applied to drm-misc-next. Thanks, Sam On Thu, Jan 16, 2020 at 10:15:06AM +0800, Jitao Shi wrote: > Changes since v8: > - merge the panel documents to one. > - delay move the drm_panel_of_backlight after drm_panel_init > > Changes since v7: > - base drm-misc-next branch > - fix document pass dt_binding_check > - remove backlight from panel driver > > Changes since v6: > - fix boe_panel_init err uninit. > - adjust the delay of backlight on. > > Changes since v5: > - covert the documents to yaml > - fine tune boe, tv101wum-n53 panel video timine > > Changes since v4: > - add auo,b101uan08.3 panel for this driver. > - add boe,tv101wum-n53 panel for this driver. > > Changes since v3: > - remove check enable_gpio. > - fine tune the auo,kd101n80-45na panel's power on timing. > > Changes since v2: > - correct the panel size > - remove blank line in Kconfig > - move auo,kd101n80-45na panel driver in this series. > > Changes since v1: > - update typo nl6 -> n16. > - update new panel config and makefile are added in alphabetically order. > - add the panel mode and panel info in driver data. > - merge auo,kd101n80-45a and boe,tv101wum-nl6 in one driver > > Jitao Shi (5): > dt-bindings: display: panel: Add boe tv101wum-n16 panel bindings > drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel > drm/panel: support for auo,kd101n80-45na wuxga dsi video mode panel > drm/panel: support for boe,tv101wum-n53 wuxga dsi video mode panel > drm/panel: support for auo,b101uan08.3 wuxga dsi video mode panel > > .../display/panel/boe,tv101wum-nl6.yaml | 81 ++ > drivers/gpu/drm/panel/Kconfig | 9 + > drivers/gpu/drm/panel/Makefile| 1 + > .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 854 ++ > 4 files changed, 945 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml > create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c > > -- > 2.21.0 > ___ > 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 v9 1/5] dt-bindings: display: panel: Add boe tv101wum-n16 panel bindings
Hi Jitao.
On Fri, Jan 17, 2020 at 07:08:17PM +0100, Sam Ravnborg wrote:
> Hi Jitao.
>
> Looks good, much better than the individual files.
> Rob Herring is still listed as maintainer which I questioned in last
> feedback.
>
> With this resolved (kept only if Rob confirms), this is
> Reviewed-by: Sam Ravnborg
Rob confirmed on irc that he is not a dedicated reviewer of this
binding. And furhtermore that it was OK I committed trivial panel
bindings.
Dropepd Rob and applied to drm-misc-next.
Sam
>
> On Thu, Jan 16, 2020 at 10:15:07AM +0800, Jitao Shi wrote:
> > Add documentation for "boe,tv101wum-n16", "auo,kd101n80-45na",
> > "boe,tv101wum-n53" and "auo,b101uan08.3" panels.
> >
> > Signed-off-by: Jitao Shi
> > Reviewed-by: Sam Ravnborg
> > ---
> > .../display/panel/boe,tv101wum-nl6.yaml | 81 +++
> > 1 file changed, 81 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> > b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> > new file mode 100644
> > index ..cc4e058f5eee
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> > @@ -0,0 +1,81 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: BOE TV101WUM-NL6 DSI Display Panel
> > +
> > +maintainers:
> > + - Thierry Reding
> > + - Sam Ravnborg
> > + - Rob Herring
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +enum:
> > +# BOE TV101WUM-NL6 10.1" WUXGA TFT LCD panel
> > + - boe,tv101wum-nl6
> > +# AUO KD101N80-45NA 10.1" WUXGA TFT LCD panel
> > + - auo,kd101n80-45na
> > +# BOE TV101WUM-N53 10.1" WUXGA TFT LCD panel
> > + - boe,tv101wum-n53
> > +# AUO B101UAN08.3 10.1" WUXGA TFT LCD panel
> > + - auo,b101uan08.3
> > +
> > + reg:
> > +description: the virtual channel number of a DSI peripheral
> > +
> > + enable-gpios:
> > +description: a GPIO spec for the enable pin
> > +
> > + pp1800-supply:
> > +description: core voltage supply
> > +
> > + avdd-supply:
> > +description: phandle of the regulator that provides positive voltage
> > +
> > + avee-supply:
> > +description: phandle of the regulator that provides negative voltage
> > +
> > + backlight:
> > +description: phandle of the backlight device attached to the panel
> > +
> > + port: true
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - enable-gpios
> > + - pp1800-supply
> > + - avdd-supply
> > + - avee-supply
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +dsi {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +panel@0 {
> > +compatible = "boe,tv101wum-nl6";
> > +reg = <0>;
> > +enable-gpios = <&pio 45 0>;
> > +avdd-supply = <&ppvarn_lcd>;
> > +avee-supply = <&ppvarp_lcd>;
> > +pp1800-supply = <&pp1800_lcd>;
> > +backlight = <&backlight_lcd0>;
> > +status = "okay";
> > +port {
> > +panel_in: endpoint {
> > +remote-endpoint = <&dsi_out>;
> > +};
> > +};
> > +};
> > +};
> > +
> > +...
> > --
> > 2.21.0
> > ___
> > 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/msm: Add syncobj support.
On Fri, Jan 17, 2020 at 12:04:17AM +0100, Bas Nieuwenhuizen wrote:
> This
>
> 1) Enables core DRM syncobj support.
> 2) Adds options to the submission ioctl to wait/signal syncobjs.
>
> Just like the wait fence fd, this does inline waits. Using the
> scheduler would be nice but I believe it is out of scope for
> this work.
>
> Support for timeline syncobjs is implemented and the interface
> is ready for it, but I'm not enabling it yet until there is
> some code for turnip to use it.
>
> The reset is mostly in there because in the presence of waiting
> and signalling the same semaphores, resetting them after
> signalling can become very annoying.
>
> v2:
> - Fixed style issues
> - Removed a cleanup issue in a failure case
> - Moved to a copy_from_user per syncobj
A few nits, but nothing serious. This is looking good, thanks for the quick
turn around.
> Signed-off-by: Bas Nieuwenhuizen
> ---
> drivers/gpu/drm/msm/msm_drv.c| 6 +-
> drivers/gpu/drm/msm/msm_gem_submit.c | 236 ++-
> include/uapi/drm/msm_drm.h | 24 ++-
> 3 files changed, 262 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index c84f0a8b3f2c..5246b41798df 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -37,9 +37,10 @@
> * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
> * GEM object's debug name
> * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> + * - 1.6.0 - Syncobj support
> */
> #define MSM_VERSION_MAJOR1
> -#define MSM_VERSION_MINOR5
> +#define MSM_VERSION_MINOR6
> #define MSM_VERSION_PATCHLEVEL 0
>
> static const struct drm_mode_config_funcs mode_config_funcs = {
> @@ -988,7 +989,8 @@ static struct drm_driver msm_driver = {
> .driver_features= DRIVER_GEM |
> DRIVER_RENDER |
> DRIVER_ATOMIC |
> - DRIVER_MODESET,
> + DRIVER_MODESET |
> + DRIVER_SYNCOBJ,
> .open = msm_open,
> .postclose = msm_postclose,
> .lastclose = drm_fb_helper_lastclose,
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index be5327af16fa..6c7f95fc5cfd 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -8,7 +8,9 @@
> #include
> #include
>
> +#include
> #include
> +#include
>
> #include "msm_drv.h"
> #include "msm_gpu.h"
> @@ -394,6 +396,191 @@ static void submit_cleanup(struct msm_gem_submit
> *submit)
> ww_acquire_fini(&submit->ticket);
> }
>
> +
> +struct msm_submit_post_dep {
> + struct drm_syncobj *syncobj;
> + uint64_t point;
> + struct dma_fence_chain *chain;
> +};
> +
> +static int msm_wait_deps(struct drm_device *dev,
> + struct drm_file *file,
> + uint64_t in_syncobjs_addr,
> + uint32_t nr_in_syncobjs,
> + uint32_t syncobj_stride,
> + struct msm_ringbuffer *ring,
> + struct drm_syncobj ***syncobjs)
> +{
> + struct drm_msm_gem_submit_syncobj syncobj_desc = {0};
> + int ret = 0;
> + uint32_t i, j;
> +
> + *syncobjs = kcalloc(nr_in_syncobjs, sizeof(**syncobjs),
> + GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
Perfect - I think this will do everything we want - protect us against OOM death
but also not introduce artificial constraints on object counts.
> + if (!syncobjs) {
You should be able to just return -ENOMEM here.
> + ret = -ENOMEM;
> + goto out_syncobjs;
> + }
> +
> + for (i = 0; i < nr_in_syncobjs; ++i) {
> + uint64_t address = in_syncobjs_addr + i * syncobj_stride;
> + struct dma_fence *fence;
> +
> + if (copy_from_user(&syncobj_desc,
> +u64_to_user_ptr(address),
> +min(syncobj_stride, sizeof(syncobj_desc {
> + ret = -EFAULT;
> + goto out_syncobjs;
You can just use break here.
> + }
> +
> + if (syncobj_desc.point &&
> + !drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE)) {
> + ret = -EOPNOTSUPP;
> + break;
> + }
> +
> + if (syncobj_desc.flags & ~MSM_SUBMIT_SYNCOBJ_FLAGS) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + ret = drm_syncobj_find_fence(file, syncobj_desc.handle,
> + syncobj_desc.point, 0, &fence);
> + if (ret)
> + break;
> +
> + if (!dma_fence_match_context(fence, ring->fctx->context))
Re: [PATCH v9 1/5] dt-bindings: display: panel: Add boe tv101wum-n16 panel bindings
Hi Jitao.
Looks good, much better than the individual files.
Rob Herring is still listed as maintainer which I questioned in last
feedback.
With this resolved (kept only if Rob confirms), this is
Reviewed-by: Sam Ravnborg
On Thu, Jan 16, 2020 at 10:15:07AM +0800, Jitao Shi wrote:
> Add documentation for "boe,tv101wum-n16", "auo,kd101n80-45na",
> "boe,tv101wum-n53" and "auo,b101uan08.3" panels.
>
> Signed-off-by: Jitao Shi
> Reviewed-by: Sam Ravnborg
> ---
> .../display/panel/boe,tv101wum-nl6.yaml | 81 +++
> 1 file changed, 81 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> new file mode 100644
> index ..cc4e058f5eee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> @@ -0,0 +1,81 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: BOE TV101WUM-NL6 DSI Display Panel
> +
> +maintainers:
> + - Thierry Reding
> + - Sam Ravnborg
> + - Rob Herring
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +enum:
> +# BOE TV101WUM-NL6 10.1" WUXGA TFT LCD panel
> + - boe,tv101wum-nl6
> +# AUO KD101N80-45NA 10.1" WUXGA TFT LCD panel
> + - auo,kd101n80-45na
> +# BOE TV101WUM-N53 10.1" WUXGA TFT LCD panel
> + - boe,tv101wum-n53
> +# AUO B101UAN08.3 10.1" WUXGA TFT LCD panel
> + - auo,b101uan08.3
> +
> + reg:
> +description: the virtual channel number of a DSI peripheral
> +
> + enable-gpios:
> +description: a GPIO spec for the enable pin
> +
> + pp1800-supply:
> +description: core voltage supply
> +
> + avdd-supply:
> +description: phandle of the regulator that provides positive voltage
> +
> + avee-supply:
> +description: phandle of the regulator that provides negative voltage
> +
> + backlight:
> +description: phandle of the backlight device attached to the panel
> +
> + port: true
> +
> +required:
> + - compatible
> + - reg
> + - enable-gpios
> + - pp1800-supply
> + - avdd-supply
> + - avee-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +panel@0 {
> +compatible = "boe,tv101wum-nl6";
> +reg = <0>;
> +enable-gpios = <&pio 45 0>;
> +avdd-supply = <&ppvarn_lcd>;
> +avee-supply = <&ppvarp_lcd>;
> +pp1800-supply = <&pp1800_lcd>;
> +backlight = <&backlight_lcd0>;
> +status = "okay";
> +port {
> +panel_in: endpoint {
> +remote-endpoint = <&dsi_out>;
> +};
> +};
> +};
> +};
> +
> +...
> --
> 2.21.0
> ___
> 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
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #6 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- Owner and user of tahiti parts on amdgpu with a state of the art gfx stack poping in. I own "rise of the tomb raider" which gnu/linux port is vulkan only, and vulkan is only available with the "amdgpu" kernel module (as far as I know). I have not bought "shadow of the tomb raider", which is vulkan only too (the port was coded by the same company). I did clear "rise of the tomb raider" years ago, I cannot play it anymore because the driver seems to miscompile some shaders and does gpu vm faults (from my save file). I did open a bug. I heard 'southern islands' parts (tahiti...) do suffer from a critical "mip mapping" slowdown bug. That could explain the slugginesh of those hardware parts in 3d intense games (I did almost stop playing "rise of the tomb raider" because the 3d rendering was unpleasantly not smooth enough). If you want, we can try to compare our benchmarks? -- 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: [Bug 206231] R9 280X low performance with all games
Owner and user of tahiti parts on amdgpu with a state of the art gfx stack poping in. I own "rise of the tomb raider" which gnu/linux port is vulkan only, and vulkan is only available with the "amdgpu" kernel module (as far as I know). I have not bought "shadow of the tomb raider", which is vulkan only too (the port was coded by the same company). I did clear "rise of the tomb raider" years ago, I cannot play it anymore because the driver seems to miscompile some shaders and does gpu vm faults (from my save file). I did open a bug. I heard 'southern islands' parts (tahiti...) do suffer from a critical "mip mapping" slowdown bug. That could explain the slugginesh of those hardware parts in 3d intense games (I did almost stop playing "rise of the tomb raider" because the 3d rendering was unpleasantly not smooth enough). If you want, we can try to compare our benchmarks? -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.4 002/205] drm/panfrost: Add missing check for pfdev->regulator
On Fri, Jan 17, 2020 at 04:12:27PM +, Steven Price wrote:
> On Thu, Jan 16, 2020 at 04:39:37PM +, Sasha Levin wrote:
> > From: Steven Price
> >
> > [ Upstream commit 52282163dfa651849e905886845bcf6850dd83c2 ]
>
> This commit is effectively already in 5.4. Confusingly there were two
> versions of this upstream:
>
> 52282163dfa6 ("drm/panfrost: Add missing check for pfdev->regulator")
> c90f30812a79 ("drm/panfrost: Add missing check for pfdev->regulator")
>
> It got merged both through a -fixes branch and through the normal merge
> window. The two copies caused a bad merge in mainline and this was
> effectively reverted in commit 603e398a3db2 ("drm/panfrost: Remove NULL
> check for regulator").
>
> c90f30812a79 is included in v5.4 so should already be in any v5.4.y
> release.
Have I mentioned this month just how much I hate the way the DRM tree
handles stable patches like this? This kind of fallout is a pain for
stable maintainers, I dred every time I see a drm patch tagged for
stable.
But we've been over this all before :(
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206141] VCE UVD ring test failed -110
https://bugzilla.kernel.org/show_bug.cgi?id=206141 --- Comment #7 from Janpieter Sollie (janpieter.sol...@dommel.be) --- Created attachment 286863 --> https://bugzilla.kernel.org/attachment.cgi?id=286863&action=edit dmesg with 2 GPUs OK, so this definitely looks like a HW failure, also tried to copy FW from working GPU to broken GPU, but it did not help. Is it possible to disable the UVD/VCE engine on the original GPU? I mean, it's not used anyway, so I might as well disable it completely to avoid these errors. -- 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 v2] drm/dp_mst: Remove VCPI while disabling topology mgr
On Mon, Dec 9, 2019 at 12:56 AM Lin, Wayne wrote:
>
>
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Saturday, December 7, 2019 3:57 AM
> > To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> > amd-...@lists.freedesktop.org
> > Cc: Kazlauskas, Nicholas ; Wentland, Harry
> > ; Zuo, Jerry ;
> > sta...@vger.kernel.org
> > Subject: Re: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology
> > mgr
> >
> > On Fri, 2019-12-06 at 14:24 -0500, Lyude Paul wrote:
> > > Reviewed-by: Lyude Paul
> > >
> > > I'll go ahead and push this to drm-misc-next-fixes right now, thanks!
> >
> > Whoops-meant to say drm-misc-next here, anyway, pushed!
> Thanks for your time!
>
I'm getting the following warning on unplug with this patch:
[ 54.010099]
[ 54.011765] ==
[ 54.018670] WARNING: possible circular locking dependency detected
[ 54.025577] 5.5.0-rc6-02274-g77381c23ee63 #47 Not tainted
[ 54.031610] --
[ 54.038516] kworker/1:6/1040 is trying to acquire lock:
[ 54.044354] 888272af3228 (&mgr->payload_lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.054957]
[ 54.054957] but task is already holding lock:
[ 54.061473] 888272af3060 (&mgr->lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
[ 54.071193]
[ 54.071193] which lock already depends on the new lock.
[ 54.071193]
[ 54.080334]
[ 54.080334] the existing dependency chain (in reverse order) is:
[ 54.088697]
[ 54.088697] -> #1 (&mgr->lock){+.+.}:
[ 54.094440]__mutex_lock+0xc3/0x498
[ 54.099015]drm_dp_mst_topology_get_port_validated+0x25/0x80
[ 54.106018]drm_dp_update_payload_part1+0xa2/0x2e2
[ 54.112051]intel_mst_pre_enable_dp+0x144/0x18f
[ 54.117791]intel_encoders_pre_enable+0x63/0x70
[ 54.123532]hsw_crtc_enable+0xa1/0x722
[ 54.128396]intel_update_crtc+0x50/0x194
[ 54.133455]skl_commit_modeset_enables+0x40c/0x540
[ 54.139485]intel_atomic_commit_tail+0x5f7/0x130d
[ 54.145418]intel_atomic_commit+0x2c8/0x2d8
[ 54.150770]drm_atomic_helper_set_config+0x5a/0x70
[ 54.156801]drm_mode_setcrtc+0x2ab/0x833
[ 54.161862]drm_ioctl+0x2e5/0x424
[ 54.166242]vfs_ioctl+0x21/0x2f
[ 54.170426]do_vfs_ioctl+0x5fb/0x61e
[ 54.175096]ksys_ioctl+0x55/0x75
[ 54.179377]__x64_sys_ioctl+0x1a/0x1e
[ 54.184146]do_syscall_64+0x5c/0x6d
[ 54.188721]entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 54.194946]
[ 54.194946] -> #0 (&mgr->payload_lock){+.+.}:
[ 54.201463]
[ 54.201463] other info that might help us debug this:
[ 54.201463]
[ 54.210410] Possible unsafe locking scenario:
[ 54.210410]
[ 54.217025]CPU0CPU1
[ 54.222082]
[ 54.227138] lock(&mgr->lock);
[ 54.230643]lock(&mgr->payload_lock);
[ 54.237742]lock(&mgr->lock);
[ 54.244062] lock(&mgr->payload_lock);
[ 54.248346]
[ 54.248346] *** DEADLOCK ***
[ 54.248346]
[ 54.254959] 7 locks held by kworker/1:6/1040:
[ 54.259822] #0: 888275c4f528 ((wq_completion)events){+.+.},
at: worker_thread+0x455/0x6e2
[ 54.269451] #1: c9000119beb0
((work_completion)(&(&dev_priv->hotplug.hotplug_work)->work)){+.+.},
at: worker_thread+0x455/0x6e2
[ 54.282768] #2: 888272a403f0 (&dev->mode_config.mutex){+.+.},
at: i915_hotplug_work_func+0x4b/0x2be
[ 54.293368] #3: 824fc6c0 (drm_connector_list_iter){.+.+},
at: i915_hotplug_work_func+0x17e/0x2be
[ 54.304061] #4: c9000119bc58 (crtc_ww_class_acquire){+.+.},
at: drm_helper_probe_detect_ctx+0x40/0xfd
[ 54.314855] #5: 888272a40470 (crtc_ww_class_mutex){+.+.}, at:
drm_modeset_lock+0x74/0xe2
[ 54.324385] #6: 888272af3060 (&mgr->lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
[ 54.334597]
[ 54.334597] stack backtrace:
[ 54.339464] CPU: 1 PID: 1040 Comm: kworker/1:6 Not tainted
5.5.0-rc6-02274-g77381c23ee63 #47
[ 54.348893] Hardware name: Google Fizz/Fizz, BIOS
Google_Fizz.10139.39.0 01/04/2018
[ 54.357451] Workqueue: events i915_hotplug_work_func
[ 54.362995] Call Trace:
[ 54.365724] dump_stack+0x71/0x9c
[ 54.369427] check_noncircular+0x91/0xbc
[ 54.373809] ? __lock_acquire+0xc9e/0xf66
[ 54.378286] ? __lock_acquire+0xc9e/0xf66
[ 54.382763] ? lock_acquire+0x175/0x1ac
[ 54.387048] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.393177] ? __mutex_lock+0xc3/0x498
[ 54.397362] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.403492] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.409620] ? drm_dp_dpcd_access+0xd9/0x101
[ 54.414390] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.420517] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.426645] ? intel_digital_port_connected+0x34d/0x35c
[
Re: [PATCH AUTOSEL 5.4 002/205] drm/panfrost: Add missing check for pfdev->regulator
On Thu, Jan 16, 2020 at 04:39:37PM +, Sasha Levin wrote:
> From: Steven Price
>
> [ Upstream commit 52282163dfa651849e905886845bcf6850dd83c2 ]
This commit is effectively already in 5.4. Confusingly there were two
versions of this upstream:
52282163dfa6 ("drm/panfrost: Add missing check for pfdev->regulator")
c90f30812a79 ("drm/panfrost: Add missing check for pfdev->regulator")
It got merged both through a -fixes branch and through the normal merge
window. The two copies caused a bad merge in mainline and this was
effectively reverted in commit 603e398a3db2 ("drm/panfrost: Remove NULL
check for regulator").
c90f30812a79 is included in v5.4 so should already be in any v5.4.y
release.
Steve
>
> When modifying panfrost_devfreq_target() to support a device without a
> regulator defined I missed the check on the error path. Let's add it.
>
> Reported-by: Dan Carpenter
> Fixes: e21dd290881b ("drm/panfrost: Enable devfreq to work without regulator")
> Signed-off-by: Steven Price
> Signed-off-by: Rob Herring
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190822093218.26014-1-steven.pr...@arm.com
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 12ff77dacc95..c1eb8cfe6aeb 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -53,8 +53,10 @@ static int panfrost_devfreq_target(struct device *dev,
> unsigned long *freq,
> if (err) {
> dev_err(dev, "Cannot set frequency %lu (%d)\n", target_rate,
> err);
> - regulator_set_voltage(pfdev->regulator, pfdev->devfreq.cur_volt,
> - pfdev->devfreq.cur_volt);
> + if (pfdev->regulator)
> + regulator_set_voltage(pfdev->regulator,
> + pfdev->devfreq.cur_volt,
> + pfdev->devfreq.cur_volt);
> return err;
> }
>
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Use new logging macros in drm/i915
On Thu, 09 Jan 2020, Wambui Karuga wrote: > This patchset continues the conversion to using the new struct > drm_device based logging macros in drm/i915. Pushed to drm-intel-next-queued, thanks for the patches. BR, Jani. > > Wambui Karuga (5): > drm/i915: conversion to new logging macros in i915/i915_vgpu.c > drm/i915: conversion to new logging macros in i915/intel_csr.c > drm/i915: conversion to new logging macros in i915/intel_device_info.c > drm/i915: convert to new logging macros in i915/intel_gvt.c > drm/i915: convert to new logging macros in i915/intel_memory_region.c > > drivers/gpu/drm/i915/i915_vgpu.c | 41 +- > drivers/gpu/drm/i915/intel_csr.c | 24 +++-- > drivers/gpu/drm/i915/intel_device_info.c | 25 +++-- > drivers/gpu/drm/i915/intel_gvt.c | 13 --- > drivers/gpu/drm/i915/intel_memory_region.c | 4 ++- > 5 files changed, 64 insertions(+), 43 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 12/18] drm/dp_mst: Add branch bandwidth validation to MST atomic check
On Fri, Jan 17, 2020 at 10:26 AM Mikita Lipski wrote: > > > > On 1/17/20 10:09 AM, Sean Paul wrote: > > On Fri, Dec 13, 2019 at 3:09 PM wrote: > >> > >> From: Mikita Lipski > >> > > > > Hi Mikita, > > Unfortunately this patch causes a crash on my i915 device when I > > unplug my MST hub. The panic is below. > > Hi Sean, > > I thought this issue was fixed by Wayne Lin in > https://patchwork.freedesktop.org/patch/346736/?series=71388&rev=1 > but now I checked it seems it never got pushed. I will resend Wayne's > patch once again. > No need to resend, I can push Wayne's patch. Thanks for the pointer, Sean > Thanks > Mikita > > > > [ 38.514014] BUG: kernel NULL pointer dereference, address: > > 0030 > > [ 38.521801] #PF: supervisor read access in kernel mode > > [ 38.527556] #PF: error_code(0x) - not-present page > > [ 38.533299] PGD 0 P4D 0 > > [ 38.536127] Oops: [#1] PREEMPT SMP PTI > > [ 38.540798] CPU: 1 PID: 1324 Comm: DrmThread Not tainted > > 5.5.0-rc6-02273-g9bb4096398e7 #36 > > [ 38.550040] Hardware name: Google Fizz/Fizz, BIOS > > Google_Fizz.10139.39.0 01/04/2018 > > [ 38.558606] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 > > [ 38.565418] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 > > 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d > > 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 > > 18 4c > > [ 38.586422] RSP: 0018:c9000139f9d8 EFLAGS: 00010282 > > [ 38.592264] RAX: RBX: 888272aeac88 RCX: > > 888236f529e0 > > [ 38.600242] RDX: 888272aeac88 RSI: 888236f529e0 RDI: > > > > [ 38.608220] RBP: c9000139fa00 R08: 0031 R09: > > 000e > > [ 38.616198] R10: 888236f529e8 R11: 8882621f3440 R12: > > > > [ 38.624176] R13: 888236f529d0 R14: 0030 R15: > > 888236f529e0 > > [ 38.632153] FS: 7cd9229ce700() GS:888276c8() > > knlGS: > > [ 38.641193] CS: 0010 DS: ES: CR0: 80050033 > > [ 38.647616] CR2: 0030 CR3: 0002618e8004 CR4: > > 003606e0 > > [ 38.655593] Call Trace: > > [ 38.658329] drm_dp_mst_atomic_check+0x152/0x16d > > [ 38.663484] intel_atomic_check+0xcfe/0x1e6f > > [ 38.668259] ? trace_hardirqs_on+0x28/0x3d > > [ 38.672835] ? intel_pipe_config_compare+0x1b38/0x1b38 > > [ 38.678580] drm_atomic_check_only+0x5ab/0x70f > > [ 38.683547] ? drm_atomic_set_crtc_for_connector+0xf5/0x102 > > [ 38.689778] ? drm_atomic_helper_shutdown+0xb6/0xb6 > > [ 38.695221] drm_atomic_commit+0x18/0x53 > > [ 38.699604] drm_atomic_helper_set_config+0x5a/0x70 > > [ 38.705057] drm_mode_setcrtc+0x2ab/0x833 > > [ 38.709537] ? rcu_read_unlock+0x57/0x57 > > [ 38.713920] ? drm_mode_getcrtc+0x173/0x173 > > [ 38.718594] drm_ioctl+0x2e5/0x424 > > [ 38.722392] ? drm_mode_getcrtc+0x173/0x173 > > [ 38.727069] vfs_ioctl+0x21/0x2f > > [ 38.730675] do_vfs_ioctl+0x5fb/0x61e > > [ 38.734766] ksys_ioctl+0x55/0x75 > > [ 38.738469] __x64_sys_ioctl+0x1a/0x1e > > [ 38.742659] do_syscall_64+0x5c/0x6d > > [ 38.746653] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > [ 38.752298] RIP: 0033:0x7cd92552d497 > > [ 38.756291] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 > > 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 > > 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 > > 01 48 > > [ 38.777296] RSP: 002b:7cd9229cd698 EFLAGS: 0246 ORIG_RAX: > > 0010 > > [ 38.785762] RAX: ffda RBX: 20323373da80 RCX: > > 7cd92552d497 > > [ 38.793740] RDX: 7cd9229cd6d0 RSI: c06864a2 RDI: > > 001c > > [ 38.801717] RBP: 7cd9229cd6c0 R08: R09: > > > > [ 38.809693] R10: R11: 0246 R12: > > 001c > > [ 38.817670] R13: R14: 7cd9229cd6d0 R15: > > c06864a2 > > [ 38.825642] Modules linked in: xt_nat cdc_ether r8152 bridge stp > > llc usbhid btusb btrtl btbcm btintel bluetooth asix usbnet > > ecdh_generic ecc mii snd_soc_hdac_hdmi snd_soc_dmic xhci_pci xhci_hcd > > snd_soc_skl snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core > > snd_intel_dspcfg snd_hda_core usbcore usb_common acpi_als kfifo_buf > > industrialio xt_MASQUERADE iptable_nat nf_nat xt_mark fuse > > ip6table_filter iwlmvm mac80211 r8169 realtek iwlwifi lzo_rle > > lzo_compress zram cfg80211 > > [ 38.871839] CR2: 0030 > > [ 38.875542] ---[ end trace 6bb39ec52e30c7cb ]--- > > [ 38.886142] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 > > [ 38.892957] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 > > 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d > > 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 > > 18 4c > > [ 38.
[PATCH v3 2/2] drm/modes: Allow DRM_MODE_ROTATE_0 when applying video mode parameters
At the moment, only DRM_MODE_ROTATE_180 is allowed when we try to apply the rotation from the video mode parameters. It is also useful to allow DRM_MODE_ROTATE_0 in case there is only a reflect option in the video mode parameter (e.g. video=540x960,reflect_x). DRM_MODE_ROTATE_0 means "no rotation" and should therefore not require any special handling, so we can just add it to the if condition. Signed-off-by: Stephan Gerhold --- drivers/gpu/drm/drm_client_modeset.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c index 895b73f23079..29367b6506a8 100644 --- a/drivers/gpu/drm/drm_client_modeset.c +++ b/drivers/gpu/drm/drm_client_modeset.c @@ -879,7 +879,8 @@ bool drm_client_rotation(struct drm_mode_set *modeset, unsigned int *rotation) * depending on the hardware this may require the framebuffer * to be in a specific tiling format. */ - if ((*rotation & DRM_MODE_ROTATE_MASK) != DRM_MODE_ROTATE_180 || + if (((*rotation & DRM_MODE_ROTATE_MASK) != DRM_MODE_ROTATE_0 && +(*rotation & DRM_MODE_ROTATE_MASK) != DRM_MODE_ROTATE_180) || !plane->rotation_property) return false; -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] drm/modes: Apply video parameters with only reflect option
At the moment, video mode parameters like video=540x960,reflect_x, (without rotation set) are not taken into account when applying the mode in drm_client_modeset.c. One of the reasons for this is that the calculation that combines the panel_orientation with cmdline->rotation_reflection does not handle the case when cmdline->rotation_reflection does not have any rotation set. (i.e. cmdline->rotation_reflection & DRM_MODE_ROTATE_MASK == 0) However, we really should not generate such a value in the first place. Rotation values should have exactly one rotation angle set (DRM_MODE_ROTATE_0 for "no rotation"). This patch set changes the command line parser to make sure that we generate only valid rotation values (defaulting to DRM_MODE_ROTATE_0). Finally it allows DRM_MODE_ROTATE_0 when applying the rotation from the video mode parameters to make parameters without rotation work correctly. Changes in v3: - Fix the cmdline parser to generate only valid rotation values instead. (There should be exactly one rotation angle in a rotation value.) - Removed most of the original patch - combining the rotations works correctly if we only have valid rotation values v2: https://lore.kernel.org/dri-devel/20191216171017.173326-1-step...@gerhold.net/ - Clarified commit message - parameters are parsed correctly, but not taken into account when applying the mode. v1: https://lore.kernel.org/dri-devel/20191209183254.211428-1-step...@gerhold.net/ Stephan Gerhold (2): drm/modes: Make sure to parse valid rotation value from cmdline drm/modes: Allow DRM_MODE_ROTATE_0 when applying video mode parameters drivers/gpu/drm/drm_client_modeset.c | 3 ++- drivers/gpu/drm/drm_modes.c | 7 +++ drivers/gpu/drm/selftests/drm_cmdline_selftests.h | 1 + .../gpu/drm/selftests/test-drm_cmdline_parser.c | 15 +-- 4 files changed, 23 insertions(+), 3 deletions(-) -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm/modes: Make sure to parse valid rotation value from cmdline
A rotation value should have exactly one rotation angle.
At the moment there is no validation for this when parsing video=
parameters from the command line. This causes problems later on
when we try to combine the command line rotation with the panel
orientation.
To make sure that we generate a valid rotation value:
- Set DRM_MODE_ROTATE_0 by default (if no rotate= option is set)
- Validate that there is exactly one rotation angle set
(i.e. specifying the rotate= option multiple times is invalid)
Signed-off-by: Stephan Gerhold
---
drivers/gpu/drm/drm_modes.c | 7 +++
drivers/gpu/drm/selftests/drm_cmdline_selftests.h | 1 +
.../gpu/drm/selftests/test-drm_cmdline_parser.c | 15 +--
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 10336b144c72..d4d64518e11b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1698,6 +1698,13 @@ static int drm_mode_parse_cmdline_options(const char
*str,
if (rotation && freestanding)
return -EINVAL;
+ if (!(rotation & DRM_MODE_ROTATE_MASK))
+ rotation |= DRM_MODE_ROTATE_0;
+
+ /* Make sure there is exactly one rotation defined */
+ if (!is_power_of_2(rotation & DRM_MODE_ROTATE_MASK))
+ return -EINVAL;
+
mode->rotation_reflection = rotation;
return 0;
diff --git a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
index ceac7af9a172..29e367db6118 100644
--- a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
@@ -53,6 +53,7 @@ cmdline_test(drm_cmdline_test_rotate_0)
cmdline_test(drm_cmdline_test_rotate_90)
cmdline_test(drm_cmdline_test_rotate_180)
cmdline_test(drm_cmdline_test_rotate_270)
+cmdline_test(drm_cmdline_test_rotate_multiple)
cmdline_test(drm_cmdline_test_rotate_invalid_val)
cmdline_test(drm_cmdline_test_rotate_truncated)
cmdline_test(drm_cmdline_test_hmirror)
diff --git a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
index 520f3e66a384..d96cd890def6 100644
--- a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
+++ b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
@@ -856,6 +856,17 @@ static int drm_cmdline_test_rotate_270(void *ignored)
return 0;
}
+static int drm_cmdline_test_rotate_multiple(void *ignored)
+{
+ struct drm_cmdline_mode mode = { };
+
+
FAIL_ON(drm_mode_parse_command_line_for_connector("720x480,rotate=0,rotate=90",
+ &no_connector,
+ &mode));
+
+ return 0;
+}
+
static int drm_cmdline_test_rotate_invalid_val(void *ignored)
{
struct drm_cmdline_mode mode = { };
@@ -888,7 +899,7 @@ static int drm_cmdline_test_hmirror(void *ignored)
FAIL_ON(!mode.specified);
FAIL_ON(mode.xres != 720);
FAIL_ON(mode.yres != 480);
- FAIL_ON(mode.rotation_reflection != DRM_MODE_REFLECT_X);
+ FAIL_ON(mode.rotation_reflection != (DRM_MODE_ROTATE_0 |
DRM_MODE_REFLECT_X));
FAIL_ON(mode.refresh_specified);
@@ -913,7 +924,7 @@ static int drm_cmdline_test_vmirror(void *ignored)
FAIL_ON(!mode.specified);
FAIL_ON(mode.xres != 720);
FAIL_ON(mode.yres != 480);
- FAIL_ON(mode.rotation_reflection != DRM_MODE_REFLECT_Y);
+ FAIL_ON(mode.rotation_reflection != (DRM_MODE_ROTATE_0 |
DRM_MODE_REFLECT_Y));
FAIL_ON(mode.refresh_specified);
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #5 from kentosama (kentos...@whiteninjastudio.com) --- (In reply to Alex Deucher from comment #3) > radeonsi is the mesa OpenGL driver and runs over both radeon and amdgpu. > Are you actually using the radeon kernel driver? Yes, i use the radeon driver after comment this line in /etc/modprobe.d/blacklist.conf : #blacklist radeon Actually i run on radeon driver. -- 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 v9 12/18] drm/dp_mst: Add branch bandwidth validation to MST atomic check
On 1/17/20 10:09 AM, Sean Paul wrote: On Fri, Dec 13, 2019 at 3:09 PM wrote: From: Mikita Lipski Hi Mikita, Unfortunately this patch causes a crash on my i915 device when I unplug my MST hub. The panic is below. Hi Sean, I thought this issue was fixed by Wayne Lin in https://patchwork.freedesktop.org/patch/346736/?series=71388&rev=1 but now I checked it seems it never got pushed. I will resend Wayne's patch once again. Thanks Mikita [ 38.514014] BUG: kernel NULL pointer dereference, address: 0030 [ 38.521801] #PF: supervisor read access in kernel mode [ 38.527556] #PF: error_code(0x) - not-present page [ 38.533299] PGD 0 P4D 0 [ 38.536127] Oops: [#1] PREEMPT SMP PTI [ 38.540798] CPU: 1 PID: 1324 Comm: DrmThread Not tainted 5.5.0-rc6-02273-g9bb4096398e7 #36 [ 38.550040] Hardware name: Google Fizz/Fizz, BIOS Google_Fizz.10139.39.0 01/04/2018 [ 38.558606] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 [ 38.565418] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 18 4c [ 38.586422] RSP: 0018:c9000139f9d8 EFLAGS: 00010282 [ 38.592264] RAX: RBX: 888272aeac88 RCX: 888236f529e0 [ 38.600242] RDX: 888272aeac88 RSI: 888236f529e0 RDI: [ 38.608220] RBP: c9000139fa00 R08: 0031 R09: 000e [ 38.616198] R10: 888236f529e8 R11: 8882621f3440 R12: [ 38.624176] R13: 888236f529d0 R14: 0030 R15: 888236f529e0 [ 38.632153] FS: 7cd9229ce700() GS:888276c8() knlGS: [ 38.641193] CS: 0010 DS: ES: CR0: 80050033 [ 38.647616] CR2: 0030 CR3: 0002618e8004 CR4: 003606e0 [ 38.655593] Call Trace: [ 38.658329] drm_dp_mst_atomic_check+0x152/0x16d [ 38.663484] intel_atomic_check+0xcfe/0x1e6f [ 38.668259] ? trace_hardirqs_on+0x28/0x3d [ 38.672835] ? intel_pipe_config_compare+0x1b38/0x1b38 [ 38.678580] drm_atomic_check_only+0x5ab/0x70f [ 38.683547] ? drm_atomic_set_crtc_for_connector+0xf5/0x102 [ 38.689778] ? drm_atomic_helper_shutdown+0xb6/0xb6 [ 38.695221] drm_atomic_commit+0x18/0x53 [ 38.699604] drm_atomic_helper_set_config+0x5a/0x70 [ 38.705057] drm_mode_setcrtc+0x2ab/0x833 [ 38.709537] ? rcu_read_unlock+0x57/0x57 [ 38.713920] ? drm_mode_getcrtc+0x173/0x173 [ 38.718594] drm_ioctl+0x2e5/0x424 [ 38.722392] ? drm_mode_getcrtc+0x173/0x173 [ 38.727069] vfs_ioctl+0x21/0x2f [ 38.730675] do_vfs_ioctl+0x5fb/0x61e [ 38.734766] ksys_ioctl+0x55/0x75 [ 38.738469] __x64_sys_ioctl+0x1a/0x1e [ 38.742659] do_syscall_64+0x5c/0x6d [ 38.746653] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 38.752298] RIP: 0033:0x7cd92552d497 [ 38.756291] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 01 48 [ 38.777296] RSP: 002b:7cd9229cd698 EFLAGS: 0246 ORIG_RAX: 0010 [ 38.785762] RAX: ffda RBX: 20323373da80 RCX: 7cd92552d497 [ 38.793740] RDX: 7cd9229cd6d0 RSI: c06864a2 RDI: 001c [ 38.801717] RBP: 7cd9229cd6c0 R08: R09: [ 38.809693] R10: R11: 0246 R12: 001c [ 38.817670] R13: R14: 7cd9229cd6d0 R15: c06864a2 [ 38.825642] Modules linked in: xt_nat cdc_ether r8152 bridge stp llc usbhid btusb btrtl btbcm btintel bluetooth asix usbnet ecdh_generic ecc mii snd_soc_hdac_hdmi snd_soc_dmic xhci_pci xhci_hcd snd_soc_skl snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_intel_dspcfg snd_hda_core usbcore usb_common acpi_als kfifo_buf industrialio xt_MASQUERADE iptable_nat nf_nat xt_mark fuse ip6table_filter iwlmvm mac80211 r8169 realtek iwlwifi lzo_rle lzo_compress zram cfg80211 [ 38.871839] CR2: 0030 [ 38.875542] ---[ end trace 6bb39ec52e30c7cb ]--- [ 38.886142] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 [ 38.892957] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 18 4c [ 38.913964] RSP: 0018:c9000139f9d8 EFLAGS: 00010282 [ 38.919804] RAX: RBX: 888272aeac88 RCX: 888236f529e0 [ 38.927784] RDX: 888272aeac88 RSI: 888236f529e0 RDI: [ 38.935765] RBP: c9000139fa00 R08: 0031 R09: 000e [ 38.943733] R10: 888236f529e8 R11: 8882621f3440 R12: [ 38.951712] R13: 888236f529d0 R14: 0030 R15: 888236f529e0 [ 38.959692] FS: 7cd9229ce700() GS:888276c8() knlGS:0
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #4 from Michel Dänzer (mic...@daenzer.net) --- (In reply to Alex Deucher from comment #3) > Are you actually using the radeon kernel driver? "DRM 2.50.0" says yes. :) -- 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 v9 12/18] drm/dp_mst: Add branch bandwidth validation to MST atomic check
On Fri, Dec 13, 2019 at 3:09 PM wrote: > > From: Mikita Lipski > Hi Mikita, Unfortunately this patch causes a crash on my i915 device when I unplug my MST hub. The panic is below. [ 38.514014] BUG: kernel NULL pointer dereference, address: 0030 [ 38.521801] #PF: supervisor read access in kernel mode [ 38.527556] #PF: error_code(0x) - not-present page [ 38.533299] PGD 0 P4D 0 [ 38.536127] Oops: [#1] PREEMPT SMP PTI [ 38.540798] CPU: 1 PID: 1324 Comm: DrmThread Not tainted 5.5.0-rc6-02273-g9bb4096398e7 #36 [ 38.550040] Hardware name: Google Fizz/Fizz, BIOS Google_Fizz.10139.39.0 01/04/2018 [ 38.558606] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 [ 38.565418] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 18 4c [ 38.586422] RSP: 0018:c9000139f9d8 EFLAGS: 00010282 [ 38.592264] RAX: RBX: 888272aeac88 RCX: 888236f529e0 [ 38.600242] RDX: 888272aeac88 RSI: 888236f529e0 RDI: [ 38.608220] RBP: c9000139fa00 R08: 0031 R09: 000e [ 38.616198] R10: 888236f529e8 R11: 8882621f3440 R12: [ 38.624176] R13: 888236f529d0 R14: 0030 R15: 888236f529e0 [ 38.632153] FS: 7cd9229ce700() GS:888276c8() knlGS: [ 38.641193] CS: 0010 DS: ES: CR0: 80050033 [ 38.647616] CR2: 0030 CR3: 0002618e8004 CR4: 003606e0 [ 38.655593] Call Trace: [ 38.658329] drm_dp_mst_atomic_check+0x152/0x16d [ 38.663484] intel_atomic_check+0xcfe/0x1e6f [ 38.668259] ? trace_hardirqs_on+0x28/0x3d [ 38.672835] ? intel_pipe_config_compare+0x1b38/0x1b38 [ 38.678580] drm_atomic_check_only+0x5ab/0x70f [ 38.683547] ? drm_atomic_set_crtc_for_connector+0xf5/0x102 [ 38.689778] ? drm_atomic_helper_shutdown+0xb6/0xb6 [ 38.695221] drm_atomic_commit+0x18/0x53 [ 38.699604] drm_atomic_helper_set_config+0x5a/0x70 [ 38.705057] drm_mode_setcrtc+0x2ab/0x833 [ 38.709537] ? rcu_read_unlock+0x57/0x57 [ 38.713920] ? drm_mode_getcrtc+0x173/0x173 [ 38.718594] drm_ioctl+0x2e5/0x424 [ 38.722392] ? drm_mode_getcrtc+0x173/0x173 [ 38.727069] vfs_ioctl+0x21/0x2f [ 38.730675] do_vfs_ioctl+0x5fb/0x61e [ 38.734766] ksys_ioctl+0x55/0x75 [ 38.738469] __x64_sys_ioctl+0x1a/0x1e [ 38.742659] do_syscall_64+0x5c/0x6d [ 38.746653] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 38.752298] RIP: 0033:0x7cd92552d497 [ 38.756291] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 01 48 [ 38.777296] RSP: 002b:7cd9229cd698 EFLAGS: 0246 ORIG_RAX: 0010 [ 38.785762] RAX: ffda RBX: 20323373da80 RCX: 7cd92552d497 [ 38.793740] RDX: 7cd9229cd6d0 RSI: c06864a2 RDI: 001c [ 38.801717] RBP: 7cd9229cd6c0 R08: R09: [ 38.809693] R10: R11: 0246 R12: 001c [ 38.817670] R13: R14: 7cd9229cd6d0 R15: c06864a2 [ 38.825642] Modules linked in: xt_nat cdc_ether r8152 bridge stp llc usbhid btusb btrtl btbcm btintel bluetooth asix usbnet ecdh_generic ecc mii snd_soc_hdac_hdmi snd_soc_dmic xhci_pci xhci_hcd snd_soc_skl snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_intel_dspcfg snd_hda_core usbcore usb_common acpi_als kfifo_buf industrialio xt_MASQUERADE iptable_nat nf_nat xt_mark fuse ip6table_filter iwlmvm mac80211 r8169 realtek iwlwifi lzo_rle lzo_compress zram cfg80211 [ 38.871839] CR2: 0030 [ 38.875542] ---[ end trace 6bb39ec52e30c7cb ]--- [ 38.886142] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 [ 38.892957] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 18 4c [ 38.913964] RSP: 0018:c9000139f9d8 EFLAGS: 00010282 [ 38.919804] RAX: RBX: 888272aeac88 RCX: 888236f529e0 [ 38.927784] RDX: 888272aeac88 RSI: 888236f529e0 RDI: [ 38.935765] RBP: c9000139fa00 R08: 0031 R09: 000e [ 38.943733] R10: 888236f529e8 R11: 8882621f3440 R12: [ 38.951712] R13: 888236f529d0 R14: 0030 R15: 888236f529e0 [ 38.959692] FS: 7cd9229ce700() GS:888276c8() knlGS: [ 38.968730] CS: 0010 DS: ES: CR0: 80050033 [ 38.975144] CR2: 0030 CR3: 0002618e8004 CR4: 003606e0 [ 38.983121] Kernel panic - not syncing: Fatal exception [ 38.988967] Kernel Offset: disabled [ 38.998280]
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) --- radeonsi is the mesa OpenGL driver and runs over both radeon and amdgpu. Are you actually using the radeon kernel driver? -- 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 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #2 from kentosama (kentos...@whiteninjastudio.com) --- Hello, with the radeonsi driver, the performance is lower than the amdgpu driver. On the same scene in Tomb Raider, the graphics card displays ~ 10fps. I have a lower score with glmark2: kentosama@teradrive:~$ glmark2 -b "terrain" === glmark2 2017.07 === OpenGL Information GL_VENDOR: X.Org GL_RENDERER: AMD TAHITI (DRM 2.50.0, 5.4.0-2-amd64, LLVM 9.0.1) GL_VERSION:4.5 (Compatibility Profile) Mesa 19.3.2 === [terrain] : FPS: 1280 FrameTime: 0.781 ms === glmark2 Score: 1280 === But glxgears shows a better result kentosama@teradrive:~$ vblank_mode=0 glxgears ATTENTION: default value of option vblank_mode overridden by environment. 28092 frames in 5.0 seconds = 5618.325 FPS 29931 frames in 5.0 seconds = 5985.997 FPS 28614 frames in 5.0 seconds = 5722.756 FPS 29221 frames in 5.0 seconds = 5844.179 FPS 28387 frames in 5.0 seconds = 5677.356 FPS 29344 frames in 5.0 seconds = 5868.745 FPS 29921 frames in 5.0 seconds = 5984.118 FPS 28185 frames in 5.0 seconds = 5636.796 FPS 29347 frames in 5.0 seconds = 5869.202 FPS 29644 frames in 5.0 seconds = 5928.789 FPS 29234 frames in 5.0 seconds = 5846.652 FPS 28770 frames in 5.0 seconds = 5753.883 FPS 29134 frames in 5.0 seconds = 5826.747 FPS 29706 frames in 5.0 seconds = 5941.031 FPS 29344 frames in 5.0 seconds = 5868.780 FPS 29803 frames in 5.0 seconds = 5960.432 FPS 29425 frames in 5.0 seconds = 5884.889 FPS -- 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][next] drm/amd/display: fix for-loop with incorrectly sized loop counter
Am 17.01.2020 14:33, schrieb Colin King:
> From: Colin Ian King
>
> A for-loop is iterating from 0 up to 1000 however the loop variable count
> is a u8 and hence not large enough. Fix this by making count an int.
> Also remove the redundant initialization of count since this is never used
> and add { } on the loop statement make the loop block clearer.
>
> Addresses-Coverity: ("Operands don't affect result")
> Fixes: ed581a0ace44 ("drm/amd/display: wait for update when setting dpg test
> pattern")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 6ab298c65247..cbed738a4246 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -3680,7 +3680,7 @@ static void set_crtc_test_pattern(struct dc_link *link,
> struct pipe_ctx *odm_pipe;
> enum controller_dp_color_space controller_color_space;
> int opp_cnt = 1;
> - uint8_t count = 0;
> + int count;
>
> switch (test_pattern_color_space) {
> case DP_TEST_PATTERN_COLOR_SPACE_RGB:
> @@ -3725,11 +3725,12 @@ static void set_crtc_test_pattern(struct dc_link
> *link,
> width,
> height);
> /* wait for dpg to blank pixel data with test pattern */
> - for (count = 0; count < 1000; count++)
> + for (count = 0; count < 1000; count++) {
> if (opp->funcs->dpg_is_blanked(opp))
> break;
> else
> udelay(100);
> + }
> }
> }
> break;
Nitpick:
the else is useless you can remove it.
re,
wh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix i915_error_state_store error defination
On Fri, 17 Jan 2020, Andi Shyti wrote: > Hi Jani, > >> >> Reported-by: Hulk Robot >> > >> > I've never been a fan of non human accounts, we had this discussion >> > already in a different mailing list. Could you please find a >> > different way of giving credit to your CI system? >> >> I don't actually mind for Reported-by credits. The history is full of >> things like: >> >> Reported-by: kbuild test robot >> Reported-by: syzbot+ec24e95ea483de0a2...@syzkaller.appspotmail.com > > That's just commit log unnecessary pollution, unwanted mail > reference... no one will ever answer at l...@intel.com, why > reference it, then? It's not about that, it's about giving credit to whom credit is due. >> Care to reference the discussion? > > Here in the Samsung list we had a discussion with another Huawei > developer about the Hulk Robot: > > https://lkml.org/lkml/2019/9/4/635 Well, there's no consensus there either. Again, if they want to use that Reported-by: line, I'm fine with it. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] video: fbdev: sh_mobile_lcdcfb: add COMPILE_TEST support
On Thu, Jan 16, 2020 at 3:52 PM Bartlomiej Zolnierkiewicz
wrote:
> Add COMPILE_TEST support to sh_mobile_lcdcfb driver for better compile
> testing coverage.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] video: fbdev: sh_mobile_lcdcfb: fix sparse warnings about using incorrect types
On Thu, Jan 16, 2020 at 3:51 PM Bartlomiej Zolnierkiewicz
wrote:
> Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
>
> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
> pointer") for details. ]
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix i915_error_state_store error defination
Hi Jani, > >> Reported-by: Hulk Robot > > > > I've never been a fan of non human accounts, we had this discussion > > already in a different mailing list. Could you please find a > > different way of giving credit to your CI system? > > I don't actually mind for Reported-by credits. The history is full of > things like: > > Reported-by: kbuild test robot > Reported-by: syzbot+ec24e95ea483de0a2...@syzkaller.appspotmail.com That's just commit log unnecessary pollution, unwanted mail reference... no one will ever answer at l...@intel.com, why reference it, then? > Care to reference the discussion? Here in the Samsung list we had a discussion with another Huawei developer about the Hulk Robot: https://lkml.org/lkml/2019/9/4/635 Andi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Do things work any better when using the radeon kernel driver rather than amdgpu? -- 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 0/4] drm/i915/display: conversion to new logging macros.
On Thu, 16 Jan 2020, Wambui Karuga wrote: > This series converts the printk based logging macros in > drm/i915/display/intel_display.c to the new struct drm_device based > logging macros. This change was split into four for manageability and > due to the size of drm/i915/display/intel_display.c. Please still write more descriptive commit messages than "part N". What are your basing your patches on? Our CI uses drm-tip, and it's failing to apply the patches. BR, Jani. > > Wambui Karuga (4): > drm/i915/display: conversion to new logging macros part 1 > drm/i915/display: conversion to new logging macros part 2 > drm/i915/display: conversion to new logging macros part 3 > drm/i915/display: convert to new logging macros part 4. > > drivers/gpu/drm/i915/display/intel_display.c | 1021 ++ > 1 file changed, 596 insertions(+), 425 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/mst: Don't do atomic checks over disabled managers
Thanks for the catch! Makes sense to skip disabled managers there, but I wonder why it didn't cause a crash with amdgpu. Anyways looks good to me. Acked-by: Mikita Lipski On 1/16/20 8:58 PM, José Roberto de Souza wrote: When a main MST port is disconnected drivers should call drm_dp_mst_topology_mgr_set_mst() disabling the MST manager, this function will set manager mst_primary to NULL and it will cause the crash bellow on the next atomic check when trying to access mst_primary->port. As there is no use in running checks over managers that are not active this patch will skip it. [ 305.616450] [drm:drm_dp_mst_atomic_check] [MST PORT:cc2049e9] releases all VCPI slots [ 305.625085] [drm:drm_dp_mst_atomic_check] [MST PORT:020ab43e] releases all VCPI slots [ 305.633729] [drm:drm_dp_mst_atomic_check] [MST MGR:cdd467d4] mst state b67672eb VCPI avail=63 used=0 [ 305.644405] BUG: kernel NULL pointer dereference, address: 0030 [ 305.651448] #PF: supervisor read access in kernel mode [ 305.656640] #PF: error_code(0x) - not-present page [ 305.661807] PGD 0 P4D 0 [ 305.664396] Oops: [#1] PREEMPT SMP NOPTI [ 305.668789] CPU: 3 PID: 183 Comm: kworker/3:2 Not tainted 5.5.0-rc6+ #1404 [ 305.675703] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3201.A00.1905140358 05/14/2019 [ 305.689425] Workqueue: events drm_dp_delayed_destroy_work [ 305.694874] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0 [ 305.700306] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 b0 b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> 8b 47 30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28 [ 305.719169] RSP: 0018:c90001687b58 EFLAGS: 00010246 [ 305.724434] RAX: RBX: 003f RCX: [ 305.731611] RDX: RSI: 88849fba8cb8 RDI: [ 305.738785] RBP: R08: R09: 0001 [ 305.745962] R10: c900016879a0 R11: c900016879a5 R12: [ 305.753139] R13: R14: 8884905c9bc0 R15: [ 305.760315] FS: () GS:88849fb8() knlGS: [ 305.768452] CS: 0010 DS: ES: CR0: 80050033 [ 305.774263] CR2: 0030 CR3: 05610006 CR4: 00760ee0 [ 305.781441] PKRU: 5554 [ 305.784228] Call Trace: [ 305.786739] intel_atomic_check+0xb2e/0x2560 [i915] [ 305.791678] ? printk+0x53/0x6a [ 305.794856] ? drm_atomic_check_only+0x3e/0x810 [ 305.799417] ? __drm_dbg+0x82/0x90 [ 305.802848] drm_atomic_check_only+0x56a/0x810 [ 305.807322] drm_atomic_commit+0xe/0x50 [ 305.811185] drm_client_modeset_commit_atomic+0x1e2/0x250 [ 305.816619] drm_client_modeset_commit_force+0x4d/0x180 [ 305.821921] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0 [ 305.827963] drm_fb_helper_set_par+0x2b/0x40 [ 305.832265] drm_fb_helper_hotplug_event.part.0+0xb2/0xd0 [ 305.837755] drm_kms_helper_hotplug_event+0x21/0x30 [ 305.842694] process_one_work+0x25b/0x5b0 [ 305.846735] worker_thread+0x4b/0x3b0 [ 305.850439] kthread+0x100/0x140 [ 305.853690] ? process_one_work+0x5b0/0x5b0 [ 305.857901] ? kthread_park+0x80/0x80 [ 305.861588] ret_from_fork+0x24/0x50 [ 305.865202] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 btusb btrtl btbcm btintel bluetooth prime_numbers snd_hda_intel snd_intel_dspcfg snd_hda_codec e1000e snd_hwdep snd_hda_core thunderbolt mei_hdcp mei_me asix cdc_ether x86_pkg_temp_thermal r8152 mei coretemp usbnet snd_pcm mii crct10dif_pclmul ptp crc32_pclmul ecdh_generic ghash_clmulni_intel pps_core ecc i2c_i801 intel_lpss_pci [ 305.903096] CR2: 0030 [ 305.906431] ---[ end trace 70ee364eed801cb0 ]--- [ 305.940816] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0 [ 305.946261] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 b0 b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> 8b 47 30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28 [ 305.965125] RSP: 0018:c90001687b58 EFLAGS: 00010246 [ 305.970382] RAX: RBX: 003f RCX: [ 305.977571] RDX: RSI: 88849fba8cb8 RDI: [ 305.984747] RBP: R08: R09: 0001 [ 305.991921] R10: c900016879a0 R11: c900016879a5 R12: [ 305.999099] R13: R14: 8884905c9bc0 R15: [ 306.006271] FS: () GS:88849fb8() knlGS: [ 306.014407] CS: 0010 DS: ES: CR0: 80050033 [ 306.020185] CR2: 0030 CR3: 00048b3aa003 CR4: 00760ee0 [ 306.027404] PKRU: 5554 [ 306.030127] BUG: sleeping function called from invalid context at
[Bug 206017] Kernel 5.4.x unusable with GUI due to crashes (some hard)
https://bugzilla.kernel.org/show_bug.cgi?id=206017 Paul (paul.e.hi...@outlook.com) changed: What|Removed |Added CC||paul.e.hi...@outlook.com --- Comment #13 from Paul (paul.e.hi...@outlook.com) --- Hello! I am experiencing the same issue on 5.4.10 (Fedora 31, KDE Spin). I'm going to attempt the 'amdgpu.noretry=0' fix later today. I made the below bug report with Fedora: https://ask.fedoraproject.org/t/fedora-kde-amdgpu-issue/5026 Summarized: gpu: Radeon Vega 10 Issue: I discovered a lot of these entries within journalctl and dmesg after gui freezes: kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! Thank you! -- 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
[PATCH][next] drm/amd/display: fix for-loop with incorrectly sized loop counter
From: Colin Ian King
A for-loop is iterating from 0 up to 1000 however the loop variable count
is a u8 and hence not large enough. Fix this by making count an int.
Also remove the redundant initialization of count since this is never used
and add { } on the loop statement make the loop block clearer.
Addresses-Coverity: ("Operands don't affect result")
Fixes: ed581a0ace44 ("drm/amd/display: wait for update when setting dpg test
pattern")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 6ab298c65247..cbed738a4246 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -3680,7 +3680,7 @@ static void set_crtc_test_pattern(struct dc_link *link,
struct pipe_ctx *odm_pipe;
enum controller_dp_color_space controller_color_space;
int opp_cnt = 1;
- uint8_t count = 0;
+ int count;
switch (test_pattern_color_space) {
case DP_TEST_PATTERN_COLOR_SPACE_RGB:
@@ -3725,11 +3725,12 @@ static void set_crtc_test_pattern(struct dc_link *link,
width,
height);
/* wait for dpg to blank pixel data with test pattern */
- for (count = 0; count < 1000; count++)
+ for (count = 0; count < 1000; count++) {
if (opp->funcs->dpg_is_blanked(opp))
break;
else
udelay(100);
+ }
}
}
break;
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 19/21] drm/vkms: Convert to CRTC VBLANK callbacks
Hi
Am 16.01.20 um 00:18 schrieb Rodrigo Siqueira:
> Hi,
>
> Thanks for the patch, I reviewed and tested it. Everything looks fine
> for VKMS.
>
> Reviewed-by: Rodrigo Siqueira
> Tested-by: Rodrigo Siqueira
Thanks a lot.
Best regards
Thomas
>
> On 01/15, Thomas Zimmermann wrote:
>> VBLANK callbacks in struct drm_driver are deprecated in favor of
>> their equivalents in struct drm_crtc_funcs. Convert vkms over.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/vkms/vkms_crtc.c | 9 ++---
>> drivers/gpu/drm/vkms/vkms_drv.c | 1 -
>> drivers/gpu/drm/vkms/vkms_drv.h | 4
>> 3 files changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
>> b/drivers/gpu/drm/vkms/vkms_crtc.c
>> index 74f703b8d22a..ac85e17428f8 100644
>> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
>> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
>> @@ -76,10 +76,12 @@ static void vkms_disable_vblank(struct drm_crtc *crtc)
>> hrtimer_cancel(&out->vblank_hrtimer);
>> }
>>
>> -bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
>> - int *max_error, ktime_t *vblank_time,
>> - bool in_vblank_irq)
>> +static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
>> + int *max_error, ktime_t *vblank_time,
>> + bool in_vblank_irq)
>> {
>> +struct drm_device *dev = crtc->dev;
>> +unsigned int pipe = crtc->index;
>> struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
>> struct vkms_output *output = &vkmsdev->output;
>> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
>> @@ -154,6 +156,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
>> .atomic_destroy_state = vkms_atomic_crtc_destroy_state,
>> .enable_vblank = vkms_enable_vblank,
>> .disable_vblank = vkms_disable_vblank,
>> +.get_vblank_timestamp = vkms_get_vblank_timestamp,
>> .get_crc_sources= vkms_get_crc_sources,
>> .set_crc_source = vkms_set_crc_source,
>> .verify_crc_source = vkms_verify_crc_source,
>> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
>> b/drivers/gpu/drm/vkms/vkms_drv.c
>> index 25bd7519295f..860de052e820 100644
>> --- a/drivers/gpu/drm/vkms/vkms_drv.c
>> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
>> @@ -103,7 +103,6 @@ static struct drm_driver vkms_driver = {
>> .dumb_create= vkms_dumb_create,
>> .gem_vm_ops = &vkms_gem_vm_ops,
>> .gem_free_object_unlocked = vkms_gem_free_object,
>> -.get_vblank_timestamp = vkms_get_vblank_timestamp,
>> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>> .gem_prime_import_sg_table = vkms_prime_import_sg_table,
>>
>> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h
>> b/drivers/gpu/drm/vkms/vkms_drv.h
>> index 7d52e24564db..eda04ffba7b1 100644
>> --- a/drivers/gpu/drm/vkms/vkms_drv.h
>> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
>> @@ -111,10 +111,6 @@ struct vkms_gem_object {
>> int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
>> struct drm_plane *primary, struct drm_plane *cursor);
>>
>> -bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
>> - int *max_error, ktime_t *vblank_time,
>> - bool in_vblank_irq);
>> -
>> int vkms_output_init(struct vkms_device *vkmsdev, int index);
>>
>> struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev,
>> --
>> 2.24.1
>>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
re: drm/amd/display: make PSR static screen entry within 30 ms
Hi,
Static analysis with Coverity has detected a division by zero in the
following commit:
commit 5b5abe9526073ccbf3032d27b5864520829cdd9c
Author: Anthony Koo
Date: Mon Dec 9 17:26:34 2019 -0500
drm/amd/display: make PSR static screen entry within 30 ms
Specifically:
unsigned int vsync_rate_hz = 0;
struct dc_static_screen_params params = {0};
/* Calculate number of static frames before generating interrupt to
* enter PSR.
*/
unsigned int frame_time_microsec = 100 / vsync_rate_hz;
vsync_rate_hz is zero, and frame_time_microsec is being assigned a value
that is being divided by zero. I'm not sure why this is coded this way
and not sure what the fix is, hence I'm reporting the issue.
Colin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix i915_error_state_store error defination
On Fri, 17 Jan 2020, Andi Shyti wrote:
> Hi Zhang,
>
> On Fri, Jan 17, 2020 at 03:34:36PM +0800, Zhang Xiaoxu wrote:
>> Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error
>> capture"), function 'i915_error_state_store' was defined and used with
>> only one parameter.
>>
>> But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined
>> with two parameter.
>>
>> This may lead compile error. This patch fix it.
>>
>> Reported-by: Hulk Robot
>
> I've never been a fan of non human accounts, we had this discussion
> already in a different mailing list. Could you please find a
> different way of giving credit to your CI system?
I don't actually mind for Reported-by credits. The history is full of
things like:
Reported-by: kbuild test robot
Reported-by: syzbot+ec24e95ea483de0a2...@syzkaller.appspotmail.com
Care to reference the discussion?
BR,
Janid.
>
>> Signed-off-by: Zhang Xiaoxu
>> ---
>> drivers/gpu/drm/i915/i915_gpu_error.h | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
>> b/drivers/gpu/drm/i915/i915_gpu_error.h
>> index 9109004956bd..41c1475e1500 100644
>> --- a/drivers/gpu/drm/i915/i915_gpu_error.h
>> +++ b/drivers/gpu/drm/i915/i915_gpu_error.h
>> @@ -314,8 +314,7 @@ i915_vma_capture_finish(struct intel_gt_coredump *gt,
>> }
>>
>> static inline void
>> -i915_error_state_store(struct drm_i915_private *i915,
>> - struct i915_gpu_coredump *error)
>> +i915_error_state_store(struct i915_gpu_coredump *error)
>
> ouch! that's an oversight.
>
> Thanks for your patch,
>
> Reviewed-by: Andi Shyti
>
> Andi
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: tfp410: add pclk limits
Hi Tomi,
Thank you for the patch.
On Mon, Jan 13, 2020 at 03:45:28PM +0200, Tomi Valkeinen wrote:
> Add pixel clock limits to the driver as per TFP410 datasheet: min 25MHz,
> max 165MHz.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 6f6d6d1e60ae..f378a8f79bcb 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -167,10 +167,20 @@ static void tfp410_disable(struct drm_bridge *bridge)
> gpiod_set_value_cansleep(dvi->powerdown, 1);
> }
>
> +static enum drm_mode_status tfp410_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode
> *mode)
> +{
> + if (mode->clock < 25000 || mode->clock > 165000)
> + return MODE_BAD;
Shouldn't you return MODE_CLOCK_LOW AND MODE_CLOCK_HIGH respectively ?
Apart from that,
Reviewed-by: Laurent Pinchart
> +
> + return MODE_OK;
> +}
> +
> static const struct drm_bridge_funcs tfp410_bridge_funcs = {
> .attach = tfp410_attach,
> .enable = tfp410_enable,
> .disable= tfp410_disable,
> + .mode_valid = tfp410_mode_valid,
> };
>
> static void tfp410_hpd_work_func(struct work_struct *work)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix i915_error_state_store error defination
Hi Zhang,
On Fri, Jan 17, 2020 at 03:34:36PM +0800, Zhang Xiaoxu wrote:
> Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error
> capture"), function 'i915_error_state_store' was defined and used with
> only one parameter.
>
> But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined
> with two parameter.
>
> This may lead compile error. This patch fix it.
>
> Reported-by: Hulk Robot
I've never been a fan of non human accounts, we had this discussion
already in a different mailing list. Could you please find a
different way of giving credit to your CI system?
> Signed-off-by: Zhang Xiaoxu
> ---
> drivers/gpu/drm/i915/i915_gpu_error.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
> b/drivers/gpu/drm/i915/i915_gpu_error.h
> index 9109004956bd..41c1475e1500 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.h
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.h
> @@ -314,8 +314,7 @@ i915_vma_capture_finish(struct intel_gt_coredump *gt,
> }
>
> static inline void
> -i915_error_state_store(struct drm_i915_private *i915,
> -struct i915_gpu_coredump *error)
> +i915_error_state_store(struct i915_gpu_coredump *error)
ouch! that's an oversight.
Thanks for your patch,
Reviewed-by: Andi Shyti
Andi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/5] drm/i915: Don't use VBT for detecting DPCD backlight controls
On Fri, 17 Jan 2020, Jani Nikula wrote:
> On Thu, 16 Jan 2020, Lyude Paul wrote:
>> Despite the fact that the VBT appears to have a field for specifying
>> that a system is equipped with a panel that supports standard VESA
>> backlight controls over the DP AUX channel, so far every system we've
>> spotted DPCD backlight control support on doesn't actually set this
>> field correctly and all have it set to INTEL_BACKLIGHT_DISPLAY_DDI.
>>
>> While we don't know the exact reason for this VBT misuse, talking with
>> some vendors indicated that there's a good number of laptop panels out
>> there that supposedly support both PWM backlight controls and DPCD
>> backlight controls as a workaround until Intel supports DPCD backlight
>> controls across platforms universally. This being said, the X1 Extreme
>> 2nd Gen that I have here (note that Lenovo is not the hardware vendor
>> that informed us of this) PWM backlight controls are advertised, but
>> only DPCD controls actually function. I'm going to make an educated
>> guess here and say that on systems like this one, it's likely that PWM
>> backlight controls might have been intended to work but were never
>> really tested by QA.
>>
>> Since we really need backlights to work without any extra module
>> parameters, let's take the risk here and rely on the standard DPCD caps
>> to tell us whether AUX backlight controls are supported or not. We still
>> check the VBT, but only to make sure that we don't enable DPCD backlight
>> controls on a panel that uses something other then the standard VESA
>> interfaces over AUX. Since panels using such non-standard interfaces
>> should probably have support added to i915, we'll print a warning when
>> seeing this in the VBT. We can remove this warning later if we end up
>> adding support for any custom backlight interfaces.
>>
>> Signed-off-by: Lyude Paul
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376
>> Cc: Jani Nikula
>> Cc: Perry Yuan
>> Cc: AceLan Kao
>> ---
>> .../drm/i915/display/intel_dp_aux_backlight.c| 16 ++--
>> 1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> index 77a759361c5c..3002b600635f 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> @@ -330,13 +330,17 @@ int intel_dp_aux_init_backlight_funcs(struct
>> intel_connector *intel_connector)
>> struct intel_panel *panel = &intel_connector->panel;
>> struct drm_i915_private *dev_priv = to_i915(intel_connector->base.dev);
>>
>> -if (i915_modparams.enable_dpcd_backlight == 0 ||
>> -(i915_modparams.enable_dpcd_backlight == -1 &&
>> -dev_priv->vbt.backlight.type !=
>> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE))
>> -return -ENODEV;
>> -
>> -if (!intel_dp_aux_display_control_capable(intel_connector))
>> +if (i915_modparams.enable_dpcd_backlight == 0)
>> return -ENODEV;
>> +if (i915_modparams.enable_dpcd_backlight == -1) {
>> +if (dev_priv->vbt.backlight.type
>> +== INTEL_BACKLIGHT_PANEL_DRIVER_INTERFACE) {
>> +DRM_WARN("VBT says panel uses custom panel driver
>> interface, not using DPCD backlight controls\n");
>> +return -ENODEV;
>> +}
>> +if (!intel_dp_aux_display_control_capable(intel_connector))
>> +return -ENODEV;
>
> Functionally, I'm fine with trying this. But perhaps we should check aux
> and early return first, and then check what vbt says, to reduce the
> dmesg noise.
>
> I'll probably want to see a debug message if we're enabling aux
> backlight even if dev_priv->vbt.backlight.type !=
> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE. It's the kind of debug trace
> you'll really want to get first.
So I've gone ahead and pushed patches 1-3 and 5 in this series, as they
were tested as part of the series I posted.
BR,
Jani.
>
> BR,
> Jani.
>
>
>
>> +}
>>
>> panel->backlight.setup = intel_dp_aux_setup_backlight;
>> panel->backlight.enable = intel_dp_aux_enable_backlight;
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/panfrost: Add the panfrost_gem_mapping concept
On 16/01/2020 02:15, Rob Herring wrote:
> From: Boris Brezillon
>
> With the introduction of per-FD address space, the same BO can be mapped
> in different address space if the BO is globally visible (GEM_FLINK)
> and opened in different context or if the dmabuf is self-imported. The
> current implementation does not take case into account, and attaches the
> mapping directly to the panfrost_gem_object.
>
> Let's create a panfrost_gem_mapping struct and allow multiple mappings
> per BO.
>
> The mappings are refcounted which helps solve another problem where
> mappings were torn down (GEM handle closed by userspace) while GPU
> jobs accessing those BOs were still in-flight. Jobs now keep a
> reference on the mappings they use.
>
> v2 (robh):
> - Minor review comment clean-ups from Steven
> - Use list_is_singular helper
> - Just WARN if we add a mapping when madvise state is not WILLNEED.
> With that, drop the use of object_name_lock.
>
> v3 (robh):
> - Revert returning list iterator in panfrost_gem_mapping_get()
>
> Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation")
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc:
> Signed-off-by: Boris Brezillon
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
Thanks,
Steve
> ---
> With the actual changes committed this time...
>
> drivers/gpu/drm/panfrost/panfrost_drv.c | 91 +++--
> drivers/gpu/drm/panfrost/panfrost_gem.c | 124 +++---
> drivers/gpu/drm/panfrost/panfrost_gem.h | 41 +-
> .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 3 +-
> drivers/gpu/drm/panfrost/panfrost_job.c | 13 +-
> drivers/gpu/drm/panfrost/panfrost_job.h | 1 +
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 61 +
> drivers/gpu/drm/panfrost/panfrost_mmu.h | 6 +-
> drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 34 +++--
> 9 files changed, 300 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index f61364f7c471..88b431a267af 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -78,8 +78,10 @@ static int panfrost_ioctl_get_param(struct drm_device
> *ddev, void *data, struct
> static int panfrost_ioctl_create_bo(struct drm_device *dev, void *data,
> struct drm_file *file)
> {
> + struct panfrost_file_priv *priv = file->driver_priv;
> struct panfrost_gem_object *bo;
> struct drm_panfrost_create_bo *args = data;
> + struct panfrost_gem_mapping *mapping;
>
> if (!args->size || args->pad ||
> (args->flags & ~(PANFROST_BO_NOEXEC | PANFROST_BO_HEAP)))
> @@ -95,7 +97,14 @@ static int panfrost_ioctl_create_bo(struct drm_device
> *dev, void *data,
> if (IS_ERR(bo))
> return PTR_ERR(bo);
>
> - args->offset = bo->node.start << PAGE_SHIFT;
> + mapping = panfrost_gem_mapping_get(bo, priv);
> + if (!mapping) {
> + drm_gem_object_put_unlocked(&bo->base.base);
> + return -EINVAL;
> + }
> +
> + args->offset = mapping->mmnode.start << PAGE_SHIFT;
> + panfrost_gem_mapping_put(mapping);
>
> return 0;
> }
> @@ -119,6 +128,11 @@ panfrost_lookup_bos(struct drm_device *dev,
> struct drm_panfrost_submit *args,
> struct panfrost_job *job)
> {
> + struct panfrost_file_priv *priv = file_priv->driver_priv;
> + struct panfrost_gem_object *bo;
> + unsigned int i;
> + int ret;
> +
> job->bo_count = args->bo_handle_count;
>
> if (!job->bo_count)
> @@ -130,9 +144,32 @@ panfrost_lookup_bos(struct drm_device *dev,
> if (!job->implicit_fences)
> return -ENOMEM;
>
> - return drm_gem_objects_lookup(file_priv,
> - (void __user
> *)(uintptr_t)args->bo_handles,
> - job->bo_count, &job->bos);
> + ret = drm_gem_objects_lookup(file_priv,
> + (void __user *)(uintptr_t)args->bo_handles,
> + job->bo_count, &job->bos);
> + if (ret)
> + return ret;
> +
> + job->mappings = kvmalloc_array(job->bo_count,
> +sizeof(struct panfrost_gem_mapping *),
> +GFP_KERNEL | __GFP_ZERO);
> + if (!job->mappings)
> + return -ENOMEM;
> +
> + for (i = 0; i < job->bo_count; i++) {
> + struct panfrost_gem_mapping *mapping;
> +
> + bo = to_panfrost_bo(job->bos[i]);
> + mapping = panfrost_gem_mapping_get(bo, priv);
> + if (!mapping) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + job->mappings[i] = mapping;
> + }
> +
> + return ret;
> }
>
> /**
> @@ -320,7 +357,9 @@ static int panfrost_ioc
Re: [PATCH v3 4/5] drm/i915: Don't use VBT for detecting DPCD backlight controls
On Thu, 16 Jan 2020, Lyude Paul wrote:
> Despite the fact that the VBT appears to have a field for specifying
> that a system is equipped with a panel that supports standard VESA
> backlight controls over the DP AUX channel, so far every system we've
> spotted DPCD backlight control support on doesn't actually set this
> field correctly and all have it set to INTEL_BACKLIGHT_DISPLAY_DDI.
>
> While we don't know the exact reason for this VBT misuse, talking with
> some vendors indicated that there's a good number of laptop panels out
> there that supposedly support both PWM backlight controls and DPCD
> backlight controls as a workaround until Intel supports DPCD backlight
> controls across platforms universally. This being said, the X1 Extreme
> 2nd Gen that I have here (note that Lenovo is not the hardware vendor
> that informed us of this) PWM backlight controls are advertised, but
> only DPCD controls actually function. I'm going to make an educated
> guess here and say that on systems like this one, it's likely that PWM
> backlight controls might have been intended to work but were never
> really tested by QA.
>
> Since we really need backlights to work without any extra module
> parameters, let's take the risk here and rely on the standard DPCD caps
> to tell us whether AUX backlight controls are supported or not. We still
> check the VBT, but only to make sure that we don't enable DPCD backlight
> controls on a panel that uses something other then the standard VESA
> interfaces over AUX. Since panels using such non-standard interfaces
> should probably have support added to i915, we'll print a warning when
> seeing this in the VBT. We can remove this warning later if we end up
> adding support for any custom backlight interfaces.
>
> Signed-off-by: Lyude Paul
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376
> Cc: Jani Nikula
> Cc: Perry Yuan
> Cc: AceLan Kao
> ---
> .../drm/i915/display/intel_dp_aux_backlight.c| 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 77a759361c5c..3002b600635f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -330,13 +330,17 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *intel_connector)
> struct intel_panel *panel = &intel_connector->panel;
> struct drm_i915_private *dev_priv = to_i915(intel_connector->base.dev);
>
> - if (i915_modparams.enable_dpcd_backlight == 0 ||
> - (i915_modparams.enable_dpcd_backlight == -1 &&
> - dev_priv->vbt.backlight.type !=
> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE))
> - return -ENODEV;
> -
> - if (!intel_dp_aux_display_control_capable(intel_connector))
> + if (i915_modparams.enable_dpcd_backlight == 0)
> return -ENODEV;
> + if (i915_modparams.enable_dpcd_backlight == -1) {
> + if (dev_priv->vbt.backlight.type
> + == INTEL_BACKLIGHT_PANEL_DRIVER_INTERFACE) {
> + DRM_WARN("VBT says panel uses custom panel driver
> interface, not using DPCD backlight controls\n");
> + return -ENODEV;
> + }
> + if (!intel_dp_aux_display_control_capable(intel_connector))
> + return -ENODEV;
Functionally, I'm fine with trying this. But perhaps we should check aux
and early return first, and then check what vbt says, to reduce the
dmesg noise.
I'll probably want to see a debug message if we're enabling aux
backlight even if dev_priv->vbt.backlight.type !=
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE. It's the kind of debug trace
you'll really want to get first.
BR,
Jani.
> + }
>
> panel->backlight.setup = intel_dp_aux_setup_backlight;
> panel->backlight.enable = intel_dp_aux_enable_backlight;
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND v3 2/2] drm: bridge: adv7511: Add support for ADV7535
On 17.01.2020 11:27, Andrzej Hajda wrote:
> On 07.01.2020 14:34, Bogdan Togorean wrote:
>> ADV7535 is a DSI to HDMI bridge chip like ADV7533 but it allows
>> 1080p@60Hz. v1p2 is fixed to 1.8V on ADV7535 but on ADV7533 can be 1.2V
>> or 1.8V and is configurable in a register.
>>
>> Signed-off-by: Bogdan Togorean
>> ---
>> drivers/gpu/drm/bridge/adv7511/Kconfig | 13 ++
>> drivers/gpu/drm/bridge/adv7511/Makefile | 3 +-
>> drivers/gpu/drm/bridge/adv7511/adv7511.h | 44 +++-
>> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 35 ++--
>> 4 files changed, 32 insertions(+), 63 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig
>> b/drivers/gpu/drm/bridge/adv7511/Kconfig
>> index 8a56ff81f4fb..47d4eb9e845d 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/Kconfig
>> +++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
>> @@ -4,8 +4,9 @@ config DRM_I2C_ADV7511
>> depends on OF
>> select DRM_KMS_HELPER
>> select REGMAP_I2C
>> +select DRM_MIPI_DSI
>> help
>> - Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
>> + Support for the Analog Device ADV7511(W)/13/33/35 HDMI encoders.
>>
>> config DRM_I2C_ADV7511_AUDIO
>> bool "ADV7511 HDMI Audio driver"
>> @@ -15,16 +16,8 @@ config DRM_I2C_ADV7511_AUDIO
>>Support the ADV7511 HDMI Audio interface. This is used in
>>conjunction with the AV7511 HDMI driver.
>>
>> -config DRM_I2C_ADV7533
>> -bool "ADV7533 encoder"
>> -depends on DRM_I2C_ADV7511
>> -select DRM_MIPI_DSI
>> -default y
>> -help
>> - Support for the Analog Devices ADV7533 DSI to HDMI encoder.
>> -
>> config DRM_I2C_ADV7511_CEC
>> -bool "ADV7511/33 HDMI CEC driver"
>> +bool "ADV7511/33/35 HDMI CEC driver"
>> depends on DRM_I2C_ADV7511
>> select CEC_CORE
>> default y
>> diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile
>> b/drivers/gpu/drm/bridge/adv7511/Makefile
>> index b46ebeb35fd4..d8ceb534b51f 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/Makefile
>> +++ b/drivers/gpu/drm/bridge/adv7511/Makefile
>> @@ -1,6 +1,5 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>> -adv7511-y := adv7511_drv.o
>> +adv7511-y := adv7511_drv.o adv7533.o
>> adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
>> adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
>> -adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
>> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> index 52b2adfdc877..ed9cfd944098 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> @@ -220,6 +220,10 @@
>>
>> #define ADV7533_REG_CEC_OFFSET 0x70
>>
>> +#define ADV7533_REG_SUPPLY_SELECT 0xe4
>> +
>> +#define ADV7533_V1P2_ENABLE BIT(7)
>> +
>> enum adv7511_input_clock {
>> ADV7511_INPUT_CLOCK_1X,
>> ADV7511_INPUT_CLOCK_2X,
>> @@ -320,6 +324,7 @@ struct adv7511_video_config {
>> enum adv7511_type {
>> ADV7511,
>> ADV7533,
>> +ADV7535,
>> };
>>
>> #define ADV7511_MAX_ADDRS 3
>> @@ -393,7 +398,6 @@ static inline int adv7511_cec_init(struct device *dev,
>> struct adv7511 *adv7511)
>> }
>> #endif
>>
>> -#ifdef CONFIG_DRM_I2C_ADV7533
>> void adv7533_dsi_power_on(struct adv7511 *adv);
>> void adv7533_dsi_power_off(struct adv7511 *adv);
>> void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
>> *mode);
>> @@ -402,44 +406,6 @@ int adv7533_patch_cec_registers(struct adv7511 *adv);
>> int adv7533_attach_dsi(struct adv7511 *adv);
>> void adv7533_detach_dsi(struct adv7511 *adv);
>> int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
>> -#else
>> -static inline void adv7533_dsi_power_on(struct adv7511 *adv)
>> -{
>> -}
>> -
>> -static inline void adv7533_dsi_power_off(struct adv7511 *adv)
>> -{
>> -}
>> -
>> -static inline void adv7533_mode_set(struct adv7511 *adv,
>> -const struct drm_display_mode *mode)
>> -{
>> -}
>> -
>> -static inline int adv7533_patch_registers(struct adv7511 *adv)
>> -{
>> -return -ENODEV;
>> -}
>> -
>> -static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
>> -{
>> -return -ENODEV;
>> -}
>> -
>> -static inline int adv7533_attach_dsi(struct adv7511 *adv)
>> -{
>> -return -ENODEV;
>> -}
>> -
>> -static inline void adv7533_detach_dsi(struct adv7511 *adv)
>> -{
>> -}
>> -
>> -static inline int adv7533_parse_dt(struct device_node *np, struct adv7511
>> *adv)
>> -{
>> -return -ENODEV;
>> -}
>> -#endif
>>
>> #ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
>> int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511);
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> index 9e13e466e72c..35595472e771 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> +++ b/drivers/gpu/drm/brid
Re: [RESEND v3 2/2] drm: bridge: adv7511: Add support for ADV7535
On 07.01.2020 14:34, Bogdan Togorean wrote:
> ADV7535 is a DSI to HDMI bridge chip like ADV7533 but it allows
> 1080p@60Hz. v1p2 is fixed to 1.8V on ADV7535 but on ADV7533 can be 1.2V
> or 1.8V and is configurable in a register.
>
> Signed-off-by: Bogdan Togorean
> ---
> drivers/gpu/drm/bridge/adv7511/Kconfig | 13 ++
> drivers/gpu/drm/bridge/adv7511/Makefile | 3 +-
> drivers/gpu/drm/bridge/adv7511/adv7511.h | 44 +++-
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 35 ++--
> 4 files changed, 32 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig
> b/drivers/gpu/drm/bridge/adv7511/Kconfig
> index 8a56ff81f4fb..47d4eb9e845d 100644
> --- a/drivers/gpu/drm/bridge/adv7511/Kconfig
> +++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
> @@ -4,8 +4,9 @@ config DRM_I2C_ADV7511
> depends on OF
> select DRM_KMS_HELPER
> select REGMAP_I2C
> + select DRM_MIPI_DSI
> help
> - Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
> + Support for the Analog Device ADV7511(W)/13/33/35 HDMI encoders.
>
> config DRM_I2C_ADV7511_AUDIO
> bool "ADV7511 HDMI Audio driver"
> @@ -15,16 +16,8 @@ config DRM_I2C_ADV7511_AUDIO
> Support the ADV7511 HDMI Audio interface. This is used in
> conjunction with the AV7511 HDMI driver.
>
> -config DRM_I2C_ADV7533
> - bool "ADV7533 encoder"
> - depends on DRM_I2C_ADV7511
> - select DRM_MIPI_DSI
> - default y
> - help
> - Support for the Analog Devices ADV7533 DSI to HDMI encoder.
> -
> config DRM_I2C_ADV7511_CEC
> - bool "ADV7511/33 HDMI CEC driver"
> + bool "ADV7511/33/35 HDMI CEC driver"
> depends on DRM_I2C_ADV7511
> select CEC_CORE
> default y
> diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile
> b/drivers/gpu/drm/bridge/adv7511/Makefile
> index b46ebeb35fd4..d8ceb534b51f 100644
> --- a/drivers/gpu/drm/bridge/adv7511/Makefile
> +++ b/drivers/gpu/drm/bridge/adv7511/Makefile
> @@ -1,6 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -adv7511-y := adv7511_drv.o
> +adv7511-y := adv7511_drv.o adv7533.o
> adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
> adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
> -adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> index 52b2adfdc877..ed9cfd944098 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -220,6 +220,10 @@
>
> #define ADV7533_REG_CEC_OFFSET 0x70
>
> +#define ADV7533_REG_SUPPLY_SELECT0xe4
> +
> +#define ADV7533_V1P2_ENABLE BIT(7)
> +
> enum adv7511_input_clock {
> ADV7511_INPUT_CLOCK_1X,
> ADV7511_INPUT_CLOCK_2X,
> @@ -320,6 +324,7 @@ struct adv7511_video_config {
> enum adv7511_type {
> ADV7511,
> ADV7533,
> + ADV7535,
> };
>
> #define ADV7511_MAX_ADDRS 3
> @@ -393,7 +398,6 @@ static inline int adv7511_cec_init(struct device *dev,
> struct adv7511 *adv7511)
> }
> #endif
>
> -#ifdef CONFIG_DRM_I2C_ADV7533
> void adv7533_dsi_power_on(struct adv7511 *adv);
> void adv7533_dsi_power_off(struct adv7511 *adv);
> void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
> *mode);
> @@ -402,44 +406,6 @@ int adv7533_patch_cec_registers(struct adv7511 *adv);
> int adv7533_attach_dsi(struct adv7511 *adv);
> void adv7533_detach_dsi(struct adv7511 *adv);
> int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
> -#else
> -static inline void adv7533_dsi_power_on(struct adv7511 *adv)
> -{
> -}
> -
> -static inline void adv7533_dsi_power_off(struct adv7511 *adv)
> -{
> -}
> -
> -static inline void adv7533_mode_set(struct adv7511 *adv,
> - const struct drm_display_mode *mode)
> -{
> -}
> -
> -static inline int adv7533_patch_registers(struct adv7511 *adv)
> -{
> - return -ENODEV;
> -}
> -
> -static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
> -{
> - return -ENODEV;
> -}
> -
> -static inline int adv7533_attach_dsi(struct adv7511 *adv)
> -{
> - return -ENODEV;
> -}
> -
> -static inline void adv7533_detach_dsi(struct adv7511 *adv)
> -{
> -}
> -
> -static inline int adv7533_parse_dt(struct device_node *np, struct adv7511
> *adv)
> -{
> - return -ENODEV;
> -}
> -#endif
>
> #ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
> int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511);
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 9e13e466e72c..35595472e771 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -367,7 +367,7 @@ static void adv7511_power_on(struct adv7511 *adv7511)
>*/
> regcache_sync(adv7511->regmap);
>
[Bug 206231] New: R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 Bug ID: 206231 Summary: R9 280X low performance with all games Product: Drivers Version: 2.5 Kernel Version: 5.4.0-2-amd64 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: kentos...@whiteninjastudio.com Regression: No Created attachment 286855 --> https://bugzilla.kernel.org/attachment.cgi?id=286855&action=edit Low performance and low GPU usage with Tomb Raider (Linux native) Hello, I have been experiencing performance issues with my AMD R9 280X graphics card for several months. On all games (Linux native and Proton), my performance is very low, well below the capabilities of the graphics card. The problem occurred when I migrated my system from Windows to Debian 10. I updated Debian stable to sid in order to have the latest version of the kernel and mesa. When I launch a game, the performances are low and during very complex scenes, the framerate goes down to 10/15 fps with a very low GPU use ~ 18%. The only time I've seen GPU usage hit 98% is in the main menu in Dawn of War II. Changing the graphics settings or the screen resolution changes absolutely nothing. The only game that seems to work well is Shadow Warrior, whose GPU usage rarely exceeds 70%. I have never heard the fans work since my transition to Debian so I used the radeon-profile tool to make sure the fans work manually. I forced the use of the hight profile in order to increase the memory and processor frequency as much as possible, but no difference kentosama@teradrive:~$ uname -a Linux teradrive 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux kentosama@teradrive:~$ glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: AMD Radeon HD 7900 Series (TAHITI, DRM 3.35.0, 5.4.0-2-amd64, LLVM 9.0.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.3.2 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.3.2 OpenGL shading language version string: 4.50 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.3.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions: kentosama@teradrive:~$ vblank_mode=0 glxgears ATTENTION: default value of option vblank_mode overridden by environment. 25934 frames in 5.0 seconds = 5186.741 FPS 25239 frames in 5.0 seconds = 5047.634 FPS 25109 frames in 5.0 seconds = 5021.724 FPS 26234 frames in 5.0 seconds = 5246.724 FPS 27341 frames in 5.0 seconds = 5468.155 FPS 26836 frames in 5.0 seconds = 5367.148 FPS 27233 frames in 5.0 seconds = 5446.563 FPS 26164 frames in 5.0 seconds = 5232.749 FPS 26568 frames in 5.0 seconds = 5313.582 FPS 25854 frames in 5.0 seconds = 5170.670 FPS 26857 frames in 5.0 seconds = 5371.198 FPS 25896 frames in 5.0 seconds = 5179.152 FPS 26129 frames in 5.0 seconds = 5225.626 FPS 26181 frames in 5.0 seconds = 5236.104 FPS 25873 frames in 5.0 seconds = 5174.487 FPS 26584 frames in 5.0 seconds = 5316.643 FPS 26448 frames in 5.0 seconds = 5289.565 FPS 27543 frames in 5.0 seconds = 5508.535 FPS 26074 frames in 5.0 seconds = 5214.784 FPS 26551 frames in 5.0 seconds = 5310.126 FPS 27081 frames in 5.0 seconds = 5416.005 FPS 26073 frames in 5.0 seconds = 5214.450 FPS 25781 frames in 5.0 seconds = 5156.146 FPS 26895 frames in 5.0 seconds = 5378.962 FPS 26933 frames in 5.0 seconds = 5386.433 FPS 26197 frames in 5.0 seconds = 5239.087 FPS 26348 frames in 5.0 seconds = 5269.402 FPS 27020 frames in 5.0 seconds = 5403.997 FPS 26684 frames in 5.0 seconds = 5336.700 FPS 26798 frames in 5.0 seconds = 5359.434 FPS 27071 frames in 5.0 seconds = 5414.150 FPS 26068 frames in 5.0 seconds = 5213.525 FPS 25425 frames in 5.0 seconds = 5084.933 FPS 25963 frames in 5.0 seconds = 5192.526 FPS 26528 frames in 5.0 seconds = 5305.459 FPS 29053 frames in 5.0 seconds = 5810.492 FPS 25807 frames in 5.0 seconds = 5161.248 FPS 25978 frames in 5.0 seconds = 5195.598 FPS 25677 frames in 5.0 seconds = 5135.263 FPS 26250 frames in 5.0 seconds = 5249.852 FPS 26988 frames in 5.0 seconds = 5397.509 FPS 26183 frames in 5.0 seconds = 5236.487 FPS 25639 frames in 5.0 seconds = 5127.785 FPS 26207 frames in 5.0 seconds = 5241.383 FPS 25885 frames in 5.0 seconds = 5176.901 FPS 25660 frames in 5.0 seconds = 5131.782 FPS 25256 frames in 5.0 seconds = 5051.157 FPS 26747 frames in 5.0 seconds = 5349.287 FPS 27643 frames in 5.0 seconds = 5528.397 FPS 26030 frames in 5.0 seconds = 5205.866 FPS 26480 frames in 5.0 seconds = 5295.797 FPS 2
Re: [PATCH] drm/bridge: tfp410: add pclk limits
On 13.01.2020 14:45, Tomi Valkeinen wrote:
> Add pixel clock limits to the driver as per TFP410 datasheet: min 25MHz,
> max 165MHz.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 6f6d6d1e60ae..f378a8f79bcb 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -167,10 +167,20 @@ static void tfp410_disable(struct drm_bridge *bridge)
> gpiod_set_value_cansleep(dvi->powerdown, 1);
> }
>
> +static enum drm_mode_status tfp410_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode
> *mode)
> +{
> + if (mode->clock < 25000 || mode->clock > 165000)
> + return MODE_BAD;
> +
> + return MODE_OK;
> +}
> +
> static const struct drm_bridge_funcs tfp410_bridge_funcs = {
> .attach = tfp410_attach,
> .enable = tfp410_enable,
> .disable= tfp410_disable,
> + .mode_valid = tfp410_mode_valid,
> };
>
> static void tfp410_hpd_work_func(struct work_struct *work)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
