- 26 Jun, 2020 2 commits
-
-
Nirmoy Das authored
Calculate GPU offset within vmwgfx driver itself without depending on bo->offset. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372933/Signed-off-by:
-
Harigovindan P authored
ti-sn65dsi86 bridge is enumerated as a runtime device. When suspend is triggered, PM core adds a refcount on all the devices and calls device suspend, since usage count is already incremented, runtime suspend will not be called and it kept the bridge regulators and gpios ON which resulted in platform not entering into XO shutdown. Add changes to force suspend on the runtime device during pm sleep. Signed-off-by:
Harigovindan P <harigovi@codeaurora.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200609120455.20458-1-harigovi@codeaurora.org
-
- 25 Jun, 2020 7 commits
-
-
Bhanuprakash Modem authored
[Why] It's useful to know the min and max vrr range for IGT testing. [How] Expose the min and max vfreq for the connector via a debugfs file on the connector, "vrr_range". Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range v2: * Fix the typo in max_vfreq (Manasi) * Change the name of node to i915_vrr_info so we can add other vrr info for more debug info (Manasi) * Change the VRR capable to display Yes or No (Manasi) * Fix indentation checkpatch errors (Manasi) v3: * Remove the unnecessary debug print (Manasi) v4: * Rebase v5: * Rename to vrr_range to match AMD debugfs v6: * Rebase (manasi) v7: * Fix cmpilation due to rebase v8: * Move debugfs node creation logic to DRM (Emil) * Remove AMD specific logic (Emil) v9: * Separate patch for removal of AMD specific logic (Manasi) Signed-off-by:
Bhanuprakash Modem <bhanuprakash.modem@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> CC: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by:
-
Nirmoy Das authored
Switch over to GEM VRAM's implementation to retrieve bo->offset. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Nirmoy Das authored
Calculate GEM VRAM bo's offset within vram-helper without depending on bo->offset. Signed-off-by:
-
Nirmoy Das authored
This patch removes slot->gpu_offset which is not required as VRAM and PRIV slot are in separate PCI bar. This patch also removes unused qxl_bo_gpu_offset() Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Nirmoy Das authored
Calculate GPU offset in radeon_bo_gpu_offset without depending on bo->offset. Signed-off-by:
-
Nirmoy Das authored
GPU address should belong to driver not in memory management. This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver. Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
-
Angelo Ribeiro authored
dw-mipi-dsi does not use any definition from drm_probe_helper. Coverity output: Event unnecessary_header: Including .../include/drm/drm_probe_helper.h does not provide any needed symbols. Reviewed-by:
Yannick Fertre <yannick.fertre@st.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Joao Pinto <jpinto@synopsys.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by:
Angelo Ribeiro <angelo.ribeiro@synopsys.com> Signed-off-by:
-
- 24 Jun, 2020 3 commits
-
-
Daniel Vetter authored
Just some tiny edits: - fix link to struct dma_fence - give slightly more meaningful title - the polling here is about implicit fences, explicit fences (in sync_file or drm_syncobj) also have their own polling v2: I misplaced the .rst include change corresponding to this patch. Reviewed-by:
Thomas Hellstrom <thomas.hellstrom@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612070535.1778368-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
The atomic helpers try really hard to not lose track of things, duplicating enabled tracking in the driver is at best confusing. Double-enabling or disabling is a bug in atomic helpers. In the fb_dirty function we can just assume that the fb always exists, simple display pipe helpers guarantee that the crtc is only enabled together with the output, so we always have a primary plane around. Now in the update function we need to be a notch more careful, since that can also get called when the crtc is off. And we don't want to upload frames when that's the case, so filter that out too. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
David Lechner <david@lechnology.com> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Same patch as the mipi-dbi one, atomic tracks this for us already, we just have to check the right thing. Reviewed-by:
-
- 23 Jun, 2020 25 commits
-
-
Laurent Pinchart authored
Implement the drm_bridge_funcs .detect() and .get_edid() operations, and call drm_bridge_hpd_notify() notify to report HPD. This provides the necessary API to support disabling connector creation, do so by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in dw_hdmi_bridge_attach(). Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200526011505.31884-23-laurent.pinchart+renesas@ideasonboard.com
-
Laurent Pinchart authored
To prepare for making connector creation optional in the driver, pass the drm_connector explicitly to the internal functions that require it. The functions that still access the connector from the dw_hdmi structure are dw_hdmi_connector_create() and __dw_hdmi_probe(). The former access is expected, as that's where the internal connector is created. The latter will be addressed separately. Signed-off-by:
-
Laurent Pinchart authored
Store the connector that the bridge is currently wired to in the dw_hdmi structure. This is currently identical to the connector field, but will differ once the driver supports disabling connector creation. Signed-off-by:
-
Laurent Pinchart authored
Isolate all the code related to connector creation to a new dw_hdmi_connector_create() function, to prepare for making connector creation optional. Signed-off-by:
-
Laurent Pinchart authored
To prepare for making connector creation optional in the driver, pass the drm_display_info explicitly to dw_hdmi_support_scdc(). The pointer is passed to the callers where required, particularly to the dw_hdmi_phy_ops .init() function. Signed-off-by:
-
Laurent Pinchart authored
Several internal functions take a drm_display_mode argument to configure the HDMI encoder or the HDMI PHY. They must not modify the mode, make the pointer const to enforce that. Signed-off-by:
-
Laurent Pinchart authored
The PHY .init() must not modify the mode it receives. Make the pointer const to enfore that. Signed-off-by:
-
Laurent Pinchart authored
Replace the drm_connector pointer passed to the .mode_valid() function with a const drm_display_info pointer, as that's all the function should need. Use the display info passed to the bridge .mode_valid() operation instead of retrieving it from the connector, to prepare for make connector creation optional. Signed-off-by:
-
Laurent Pinchart authored
The meson-dw-hdmi driver needs to access its own context from the .mode_valid() operation. It currently gets it from the dev_private field of the drm_device retrieved from the connector, which is a hack. Use the private data passed to the .mode_valid() operation instead. Signed-off-by:
-
Laurent Pinchart authored
The input_bus_format field of struct dw_hdmi_plat_data is unused. Remove it. Signed-off-by:
-
Laurent Pinchart authored
The .configure_phy() operation takes a dw_hdmi_plat_data pointer as a context argument. This differs from .mode_valid() that takes a custom private context pointer, causing possible confusion. Make the dw_hdmi_plat_data operations more consistent by passing the private context pointer to .configure_phy() as well. Signed-off-by:
-
Laurent Pinchart authored
Platform glue drivers for dw_hdmi may need to access device-specific data from their .mode_valid() implementation. They currently have no clean way to do so, and one driver hacks around it by accessing the dev_private data of the drm_device retrieved from the connector. Add a priv_data void pointer to the dw_hdmi_plat_data structure, and pass it to the .mode_valid() function. Signed-off-by:
-
Laurent Pinchart authored
When validating a mode, bridges may need to do so in the context of a display, as specified by drm_display_info. An example is the meson dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to perform clock calculations. Bridges that need the display info currently retrieve it from the drm_connector created by the bridge. This gets in the way of moving connector creation out of bridge drivers. To make this possible, pass the drm_display_info to drm_bridge_funcs .mode_valid(). Changes to the bridge drivers have been performed with the following coccinelle semantic patch and have been compile-tested. @ rule1 @ identifier funcs; identifier fn; @@ struct drm_bridge_funcs funcs = { ..., .mode_valid = fn }; @ depends on rule1 @ identifier rule1.fn; identifier bridge; identifier mode; @@ enum drm_mode_status fn( struct drm_bridge *bridge, + const struct drm_display_info *info, const struct drm_display_mode *mode ) { ... } Signed-off-by:Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Guido Günther <agx@sigxcpu.org> # for the nwl-dsi part: Signed-off-by:
-
Laurent Pinchart authored
The drm_hdmi_avi_infoframe_from_display_mode(), drm_hdmi_vendor_infoframe_from_display_mode() and drm_hdmi_avi_infoframe_quant_range() functions take a drm_connector that they don't modify. Mark it as const. Signed-off-by:
-
Laurent Pinchart authored
Make the connector creation optional to enable usage of the simple-bridge with the DRM bridge connector helper. Signed-off-by:
-
Laurent Pinchart authored
Instead of poking into the DT node of the next bridge for its DDC bus and implementing the .get_modes() and .detect() connector operations manually, retrieve the next bridge in the chain and delegate these operations to it. Signed-off-by:
-
Laurent Pinchart authored
The drm_bridge_get_edid() function is documented to return an error pointer on error. The underlying .get_edid() operation, however, returns NULL on error, and so do the drm_get_edid() and drm_do_get_edid() functions upon which .get_edid() is usually implemented. Make drm_bridge_get_edid() return NULL on error to be consistent. Signed-off-by:
-
Laurent Pinchart authored
Now that the driver supports all the connector-related bridge operations, make the connector creation optional. This enables usage of the adv7511 with the DRM bridge connector helper. Signed-off-by:
-
Laurent Pinchart authored
Implement the bridge connector-related .get_edid(), .detect() and .hpd_notify() operations, and report the related bridge capabilities. Output status detection is implemented using the same backend as for the DRM connector, but requires making mode retrieval at detection time optional as no pointer to the connector is available to the bridge .detect() operation. The reason for the need to retrieve modes at detection time is unclear to me, and this may benefit from further refactoring of hot plug handling code. Hot plug detection is notified through the bridge HPD notification framework when the bridge is used without creating a connector, and falls back to the existing implementation otherwise. CEC handling of disconnection is handled in the new .hpd_notify() operation in the new code path. Signed-off-by:
-
Laurent Pinchart authored
To prepare for making the connector creation optional, move the related code out of adv7511_bridge_attach() to a separate function. Signed-off-by:
-
Laurent Pinchart authored
To prepare for the implementation of the DRM bridge connector operations, move EDID read out of adv7511_get_modes() to a separate function. Signed-off-by:
-
Nirmoy Das authored
Function prepare_igt_frag() and get_insert_time() were casting signed value to unsigned value before returning error. So error check in igt_frag() would not work with unsigned return value from get_insert_time() compared against negative value. Addresses-Coverity: ("Unsigned compared against 0, no effect") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Christian König authored
Skipping just one branch of the tree is not the most effective approach. Instead use a macro to define the traversal functions and sort out both branch sides. This improves the performance of the unit tests by a factor of more than 4. Signed-off-by:
-
Christian König authored
Abort early if there isn't enough space to allocate from a subtree. Signed-off-by:
-
Christian König authored
Just some code cleanup. Signed-off-by:
-
- 22 Jun, 2020 3 commits
-
-
Thomas Zimmermann authored
Converts the ast driver to drm_info(), drm_err() and drm_WARN_*(). No functional changes are made. v2: * also convert WARN_*() macros Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Thomas Zimmermann authored
All upcasting from struct drm_device to struct ast_private is now performed via to_ast_private(). Using struct drm_device.dev_private is deprecated. The ast variable in ast_crtc_helper_atomic_check() is unused, so removed it. v2: * fix typo in commit message Signed-off-by:
-
Thomas Zimmermann authored
The driver cannot suspend before it has loaded completely. So the test for device pointers is not required. Remove it. v3: * s/them/it/ in commit message Signed-off-by:
-
