- 18 May, 2018 22 commits
-
-
Daniel Stone authored
Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we can remove it. Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Acked-by:
Heiko Stübner <heiko@sntech.de> Tested-by:
-
Daniel Stone authored
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by:
-
Daniel Stone authored
Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can just delete it. Signed-off-by:
CK Hu <ck.hu@mediatek.com> Reviewed-by:
-
Daniel Stone authored
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by:
-
Daniel Stone authored
We cannot create a framebuffer with no objects, so there's no point testing for it. v2: Remove the error entirely. (Sean, CK, Thierry) Signed-off-by:
-
Daniel Stone authored
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle function the same as the GEM framebuffer helper, we can reuse that. Signed-off-by:
-
Daniel Stone authored
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by:
-
Daniel Stone authored
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by:
Russell King <linux@armlinux.org.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-19-daniels@collabora.com
-
Daniel Stone authored
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by:
-
Daniel Stone authored
Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer, we can drop it. Signed-off-by:
-
Daniel Stone authored
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by:
-
Stefan Agner authored
All values in a struct struct timing_entry (every entry in struct display_timing) require an integer. Choose the closest safe integer of 32. This avoids a warning seen with clang: drivers/gpu/drm/panel/panel-simple.c:1250:27: warning: implicit conversion from 'double' to 'u32' (aka 'unsigned int') changes value from 33.5 to 33 [-Wliteral-conversion] .vfront_porch = { 6, 21, 33.5 }, ~ ^~~~ drivers/gpu/drm/panel/panel-simple.c:1251:26: warning: implicit conversion from 'double' to 'u32' (aka 'unsigned int') changes value from 33.5 to 33 [-Wliteral-conversion] .vback_porch = { 6, 21, 33.5 }, ~ ^~~~ Signed-off-by:Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Lucas Stach authored
The patch adding support for the AUO P320HVN03 panel was written against a preliminary datasheet, which specified JEIDA data ordering. Testing with real hardware has shown that the actually used data ordering is SPWG. Fixes: 70c0d5b7 (drm/panel: simple: add support for AUO P320HVN03) Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
spanda@codeaurora.org authored
Add support for Innolux TV123WAM, which is a 12.3" eDP display panel with 2160x1440 resolution. Changes in v1: - Add the compatibility string, display_mode and panel_desc structures in alphabetical order (Sean Paul). Signed-off-by:
Sandeep Panda <spanda@codeaurora.org> Signed-off-by:
-
spanda@codeaurora.org authored
Innolux TV123WAM is a 12.3" eDP display panel with 2160x1440 resolution, which can be supported by simple panel driver. Changes in v1: - Make use of simple panel driver instead of creating a new driver for this panel (Sean Paul). - Combine dt-binding and driver changes into one patch as done by other existing panel support changes. Changes in v2: - Separate driver change from dt-binding documentation (Rob Herring). - Add the properties from simple-panel binding that are applicable to this panel (Rob Herring). Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Thierry Reding authored
Building the driver in a configuration with !PM currently causes a warning about these operations being unused. Mark them as such to shut up the compiler. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Philippe CORNU authored
The backlight API provides new functions to enable and disable the backlight and which hide the intricacies of achieving the correct result. Signed-off-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
-
Philippe CORNU authored
Remove the message in case of probe success. This comes from a suggestion followed in the recent integration of the raydium rm68200 panel. Signed-off-by:
-
Philippe CORNU authored
The backlight 1st update was in the otm8009a_prepare() function for a bad reason: backlight was not working in video mode and the otm8009a_prepare() is in command mode for the init sequence. As the backlight is now fixed (no low-power mode), it is good to put it back in the otm8009a_enable() function, avoiding also image glitches visible on some "slow" devices. Signed-off-by:
-
Philippe CORNU authored
Backlight updates was not working anymore since the good implementation of the DSI low-power mode in the DSI host driver. After a longer analysis, the backlight updates in DSI video mode require the DSI high- speed mode. Note: it is important to keep the DSI low-power mode for the rest of the driver as init sequence, sleep in/out... DSI commands work in low-power mode. Signed-off-by:
-
Jyri Sarha authored
Add device_link from panel device (supplier) to DRM device (consumer) when drm_panel_attach() is called. This patch should protect the master DRM driver if an attached panel driver unbinds while it is in use. The device_link should make sure the DRM device is unbound before the panel driver becomes unavailable. The device_link is removed when drm_panel_detach() is called. The drm_panel_detach() should be called by the consumer DRM driver, not the panel driver, otherwise both drivers are racing to delete the same link. Signed-off-by:
Jyri Sarha <jsarha@ti.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Jyri Sarha authored
Remove all drm_panel_detach() calls from all panel drivers and update the kerneldoc for drm_panel_detach(). Setting the connector and drm to NULL when the DRM panel device is going away hardly serves any purpose. Usually the whole memory structure is freed right after the remove call. However, calling the detach function from the master DRM device, and setting the connector pointer to NULL, has the logic of marking the panel again as available for another DRM master to attach. The usual situation would be the same DRM master device binding again. Signed-off-by:
-
- 17 May, 2018 4 commits
-
-
Stanislav Lisovskiy authored
Added encoding of drm content_type property from drm_connector_state within AVI infoframe in order to properly handle external HDMI TV content-type setting. This requires also manipulationg ITC bit, as stated in HDMI spec. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. v3: * Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. v4: * Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. v5: * Moved patch revision's description to commit messages. v6: * Minor naming fix for the content type enumeration string. v7: * Fix parameter name for documentation and parameter alignment in order not to get warning. Added Content Type description to new HDMI connector properties section. v8: * Thrown away unneeded numbers from HDMI content-type property description. Switch to strings desription instead of plain definitions. v9: * Moved away hdmi specific content-type enum from drm_connector_state. Content type property should probably not be bound to any specific connector interface in drm_connector_state. Same probably should be done to hdmi_picture_aspect_ration enum which is also contained in drm_connector_state. Added special helper function to get derive hdmi specific relevant infoframe fields. v10: * Added usage description to HDMI properties kernel doc. v11: * Created centralized function for filling HDMI AVI infoframe, based on correspondent DRM property value. Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-3-stanislav.lisovskiy@intel.com [vsyrjala: clean up checkpatch multiple blank lines warnings] Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Stanislav Lisovskiy authored
Added content_type property to drm_connector_state in order to properly handle external HDMI TV content-type setting. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. v3: * Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. v4: * Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. v5: * Moved patch revision's description to commit messages. v6: * Minor naming fix for the content type enumeration string. v7: * Fix parameter name for documentation and parameter alignment in order not to get warning. Added Content Type description to new HDMI connector properties section. v8: * Thrown away unneeded numbers from HDMI content-type property description. Switch to strings desription instead of plain definitions. v9: * Moved away hdmi specific content-type enum from drm_connector_state. Content type property should probably not be bound to any specific connector interface in drm_connector_state. Same probably should be done to hdmi_picture_aspect_ration enum which is also contained in drm_connector_state. Added special helper function to get derive hdmi specific relevant infoframe fields. v10: * Added usage description to HDMI properties kernel doc. v11: * Created centralized function for filling HDMI AVI infoframe, based on correspondent DRM property value. Acked-by:
-
Philippe Cornu authored
Minor fixes detected with "scripts/checkpatch.pl --strict" Signed-off-by:
-
Maxime Ripard authored
The vc4 HVS uses an internal RGB888 representation of the frames, and will by default expand formats using a lower depth using zeros. This causes an issue when we try to use other compositing software such as pixman that fill the missing bits by repeating the higher significant bits. As such, we can't check the display output in a reliable way by doing a software composition and an hardware one and compare both. To prevent this, force the same behaviour so that we can do such things. Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
- 15 May, 2018 2 commits
-
-
Philippe Cornu authored
This patch clarifies the adjusted_mode documentation for bridges. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180409152427.12449-1-philippe.cornu@st.com
-
Colin Ian King authored
Trivial fix to spelling mistake in DRM_INFO message. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by:
-
- 14 May, 2018 3 commits
-
-
Souptick Joarder authored
Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. Reference id -> 1c8f4220 ("mm: change return type to vm_fault_t") Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180417133844.GA30256@jordon-HP-15-Notebook-PCSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Dave Airlie authored
Although the kernel doesn't use this, qemu imports these headers and it's best to keep them consistent. This define is also something userspace may want to use. Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180503021021.10694-1-airlied@gmail.comSigned-off-by:
-
Eric Anholt authored
drm_minor_alloc() does multiplication on this enum, so the removal ended up moving render nodes down from 128 base to 64. This caused Mesa's surfaceless backend to be unable to open the render nodes, since it was still looking up at 128. v2: Add a comment warning the next person. Signed-off-by:
-
- 11 May, 2018 9 commits
-
-
Maarten Lankhorst authored
drm-misc-next is still based on v4.16-rc7, and was getting a bit stale. Signed-off-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Shashank Sharma authored
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or vise versa. This patch was once reviewed and merged, and later reverted due to lack of DRM client protection, while adding aspect ratio bits in user modes. This is a re-spin of the series, with DRM client cap protection. The previous series can be found here: https://pw-emeril.freedesktop.org/series/10850/Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> (V2) Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V2) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: rebase V4: rebase V5: corrected the macro name for an aspect ratio, in a switch case. V6: rebase V7: rebase V8: rebase V9: rebase V10: rebase V11: rebase V12: rebase V13: rebase V14: rebase Acked-by:
-
Shashank Sharma authored
Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due to wrong VIC. This patch adds aspect ratio information in DRM's mode conversion and mode comparision functions, to make sure kernel picks mode with right aspect ratio (as per the VIC). Background: This patch was once reviewed and merged, and later reverted due to lack of DRM cap protection. This is a re-spin of this patch, this time with DRM cap protection, to avoid aspect ratio information, when the client doesn't request for it. Review link: https://pw-emeril.freedesktop.org/patch/104068/ Background discussion: https://patchwork.kernel.org/patch/9379057/Signed-off-by:
Lin, Jia <lin.a.jia@intel.com> Signed-off-by:
Akashdeep Sharma <akashdeep.sharma@intel.com> Reviewed-by: Jim Bride <jim.bride@linux.intel.com> (V2) Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V4) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: modified the aspect-ratio check in drm_mode_equal as per new flags provided by Ville. https://patchwork.freedesktop.org/patch/188043/ V4: rebase V5: rebase V6: As recommended by Ville, avoided matching of aspect-ratio in drm_fb_helper, while trying to find a common mode among connectors for the target clone mode. V7: rebase V8: rebase V9: rebase V10: rebase V11: rebase V12: rebase V13: rebase V14: rebase Acked-by:
-
Ankit Nautiyal authored
We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch: -prunes the modes with aspect-ratio information, from the drm_mode_get_connector modelist supplied to the user, if the user-space has not set the aspect ratio DRM client cap. However if such a mode is unique in the list, it is kept in the list, with aspect-ratio flags reset. -prepares a list of exposed modes, which is used to find unique modes if aspect-ratio is not allowed. -adds a new list_head 'exposed_head' in drm_mode_display, to traverse the list of exposed modes. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: As suggested by Ville, modified the mechanism of pruning of modes with aspect-ratio, if the aspect-ratio is not supported. Instead of straight away pruning such a mode, the mode is retained with aspect ratio bits set to zero, provided it is unique. V4: rebase V5: Addressed review comments from Ville: -used a pointer to store last valid mode. -avoided, modifying of picture_aspect_ratio in kernel mode, instead only flags bits of user mode are reset (if aspect-ratio is not supported). V6: As suggested by Ville, corrected the mode pruning logic and elaborated the mode pruning logic and the assumptions taken. V7: rebase V8: rebase V9: rebase V10: rebase V11: Fixed the issue caused in kms_3d test, and enhanced the pruning logic to correctly identify and prune modes with aspect-ratio, if aspect-ratio cap is not set. V12: As suggested by Ville, added another list_head in drm_mode_display to traverse the list of exposed modes and avoided duplication of modes. V13: Minor modifications, as suggested by Ville. v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the pruning logic to avoid any dependency in the order of mode with aspect-ratio. Reviewed-by:
-
Ankit Nautiyal authored
If the user-space does not support aspect-ratio, and requests for a modeset with mode having aspect ratio bits set, then the given user-mode must be rejected. Secondly, while preparing a user-mode from kernel mode, the aspect-ratio info must not be given, if aspect-ratio is not supported by the user. This patch: 1. rejects the modes with aspect-ratio info, during modeset, if the user does not support aspect ratio. 2. does not load the aspect-ratio info in user-mode structure, if aspect ratio is not supported. 3. adds helper functions for determining if aspect-ratio is expected in user-mode and for allowing/disallowing the aspect-ratio, if its not expected. Signed-off-by:
-
Ankit Nautiyal authored
To enable aspect-ratio support in DRM, blindly exposing the aspect ratio information along with mode, can break things in existing non-atomic user-spaces which have no intention or support to use this aspect ratio information. To avoid this, a new drm client cap is required to enable a non-atomic user-space to advertise if it supports modes with aspect-ratio. Based on this cap value, the kernel will take a call on exposing the aspect ratio info in modes or not. This patch adds the client cap for aspect-ratio. Since no atomic-userspaces blow up on receiving aspect-ratio information, the client cap for aspect-ratio is always enabled for atomic clients. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
-
Ville Syrjälä authored
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect ratios. Return an error if the user asked for something different. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: "Lin, Jia" <lin.a.jia@intel.com> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: linux-media@vger.kernel.org Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Signed-off-by:
-
Ville Syrjälä authored
If the user mode would specify an aspect ratio other than 4:3 or 16:9 we now silently ignore it. Maybe a better apporoach is to return an error? Let's try that. Also we must be careful that we don't try to send illegal picture aspect in the infoframe as it's only capable of signalling none, 4:3, and 16:9. Currently we're sending these bogus infoframes whenever the cea mode specifies some other aspect ratio. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
commit 6dffd431 ("drm: Add aspect ratio parsing in DRM layer") cause us to not send out any VICs in the AVI infoframes. That commit was since reverted, but if and when we add aspect ratio handing back we need to be more careful. Let's handle this by considering the aspect ratio as a requirement for cea mode matching only if the passed in mode actually has a non-zero aspect ratio field. This will keep userspace that doesn't provide an aspect ratio working as before by matching it to the first otherwise equal cea mode. And once userspace starts to provide the aspect ratio it will be considerd a hard requirement for the match. Also change the hdmi mode matching to use drm_mode_match() for consistency, but we don't match on aspect ratio there since the spec doesn't list a specific aspect ratio for those modes. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: "Lin, Jia" <lin.a.jia@intel.com> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
