search for: path_property

...gt;msto) && mstm->msto; i++) + for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++) drm_mode_connector_attach_encoder(&mstc->connector, &mstm->msto[i]->encoder); drm_object_attach_property(&mstc->connector.base, dev->mode_config.path_property, 0); -- 2.11.0

...have "holes" or not. Indeed. Let's see what Ben says. > >> drm_mode_connector_attach_encoder(&mstc->connector, &mstm->msto[i]->encoder); >> >> drm_object_attach_property(&mstc->connector.base, dev->mode_config.path_property, 0); >> -- >> 2.11.0 >> > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >

...^^^^^^^^^ This doesn't make sense. Maybe mstm->msto[i] was intended?? 3159 drm_mode_connector_attach_encoder(&mstc->connector, &mstm->msto[i]->encoder); 3160 3161 drm_object_attach_property(&mstc->connector.base, dev->mode_config.path_property, 0); 3162 drm_object_attach_property(&mstc->connector.base, dev->mode_config.tile_property, 0); 3163 drm_mode_connector_set_path_property(&mstc->connector, path); 3164 return 0; regards, dan carpenter

...haven't the faintest clue whether the msto array can have "holes" or not. > drm_mode_connector_attach_encoder(&mstc->connector, &mstm->msto[i]->encoder); > > drm_object_attach_property(&mstc->connector.base, dev->mode_config.path_property, 0); > -- > 2.11.0 >

...nnector_cleanup(&mstc->connector); + if (mstc->port) + drm_dp_mst_put_port_malloc(mstc->port); + kfree(mstc); } @@ -1012,6 +1016,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct drm_dp_mst_port *port, drm_object_attach_property(&mstc->connector.base, dev->mode_config.path_property, 0); drm_object_attach_property(&mstc->connector.base, dev->mode_config.tile_property, 0); drm_connector_set_path_property(&mstc->connector, path); + drm_dp_mst_get_port_malloc(port); return 0; } @@ -1077,6 +1082,7 @@ nv50_mstm_destroy_connector(struct drm_dp_mst_topology_...

...I believe the V2 patch to be correct. Ben. > > >> >>> drm_mode_connector_attach_encoder(&mstc->connector, &mstm->msto[i]->encoder); >>> >>> drm_object_attach_property(&mstc->connector.base, dev->mode_config.path_property, 0); >>> -- >>> 2.11.0 >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.ht...

...0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++) + for (i = 0; i < ARRAY_SIZE(mstm->msto); i++) drm_mode_connector_attach_encoder(&mstc->connector, &mstm->msto[i]->encoder); drm_object_attach_property(&mstc->connector.base, dev->mode_config.path_property, 0); -- 2.11.0

On the ThinkPad P71, we have one eDP connector exposed along with 5 DP connectors, resulting in a total of 11 TMDS encoders. Since the GPU on this system is also capable of MST, we create an additional 4 fake MST encoders for each DP port. Unfortunately, we also do this for the eDP port as well, resulting in: 1 eDP port: +1 TMDS encoder +4 DPMST encoders 5 DP ports: +2 TMDS

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

This is a WIP version of the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a