- 12 Jan, 2018 1 commit
-
-
Linus Walleij authored
This adds device tree bindings for the Texas Instruments THS8134, THS8134A and THS8134B VGA DACs by extending and renaming the existing bindings for THS8135. These DACs are used for the VGA outputs on the ARM reference designs such as Integrator, Versatile and RealView. Cc: devicetree@vger.kernel.org Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180112074854.9560-1-linus.walleij@linaro.org
-
- 11 Jan, 2018 1 commit
-
-
Noralf Trønnes authored
Remove a couple of trailing spaces. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
- 10 Jan, 2018 1 commit
-
-
Maarten Lankhorst authored
This reverts commit a10195bb. This commit needs some more thought, and is currently crashing kms_flip tests. Until we figure out what's going wrong it's better to revert, and also next time apply it to drm-misc-fixes. Testcase: kms_flip Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104566 References: https://patchwork.freedesktop.org/series/36185/ References: https://patchwork.freedesktop.org/series/36250/Reported-by:
Marta Löfstedt <marta.lofstedt@intel.com> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- 09 Jan, 2018 5 commits
-
-
Samuel Li authored
Signed-off-by:
Samuel Li <Samuel.Li@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1515100334-6845-1-git-send-email-Samuel.Li@amd.com
-
Leo (Sunpeng) Li authored
During a non-blocking commit, it is possible to return before the commit_tail work is queued (-ERESTARTSYS, for example). Since a reference on the crtc commit object is obtained for the pending vblank event when preparing the commit, the above situation will leave us with an extra reference. Therefore, if the commit_tail worker has not consumed the event at the end of a commit, release it's reference. Signed-off-by:
Leo (Sunpeng) Li <sunpeng.li@amd.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Brian Norris authored
Bridge drivers/helpers shouldn't be clobbering the drvdata, since a parent driver might need to own this. Instead, let's return our 'dw_mipi_dsi' object and have callers pass that back to us for removal. Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171128010538.119114-1-briannorris@chromium.org
-
Philippe CORNU authored
Add the 8-bit clut mode support at crtc level. Useful for low memory footprint user interfaces but also for 8-bit old games (including color shifting visual effects). Tested with fbdev FBIOPUTCMAP & drm DRM_IOCTL_MODE_SETGAMMA ioctls. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/1509016666-18927-1-git-send-email-philippe.cornu@st.com
-
Sylwester Nawrocki authored
This patch removes an unreachable code found by the SVACE static analysis: UNREACHABLE_CODE: This statement in the source code might be unreachable during program execution. [unreachable] unreachable at drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:787 retval != 0 is always false because at this program point the variable retval is always equal to 0 at drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:786 Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
- 05 Jan, 2018 2 commits
-
-
Maxime Ripard authored
A significant number of panels need to power up a regulator in order to operate properly. Add support for the power-supply property to enable and disable such a regulator whenever needed. Reviewed-by:
Chen-Yu Tsai <wens@csie.org> Reviewed-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/0c0819bdf88fa948188df95e57a10820a8a4548d.1513854122.git-series.maxime.ripard@free-electrons.com
-
Maxime Ripard authored
The power-supply property is used by a vast majority of panels, including panel-simple. Let's document it as a common property Acked-by:
-
- 04 Jan, 2018 6 commits
-
-
Maxime Ripard authored
Add support for the A83T display pipeline. Reviewed-by:
-
Maxime Ripard authored
The TCON supports the LVDS interface to output to a panel or a bridge. Let's add support for it. Reviewed-by:
-
Maxime Ripard authored
The various outputs the TCON can provide have different constraints on the dotclock divider. Let's make them configurable by the various mode_set functions. Reviewed-by:
-
Maxime Ripard authored
It seems like the mixer can only run properly when clocked at 150MHz. In order to have something more robust than simply a fire-and-forget assigned-clocks-rate, let's put that in the code. Reviewed-by:
-
Maxime Ripard authored
The A83T has two video pipelines in parallel that looks quite similar to the other SoCs. The video planes are handled through a controller called the mixer, and the video signal is then passed to the timing controller (TCON). And while there is two instances of the mixers and TCONs, they have a significant number of differences. The TCONs are quite easy to deal with, one is supposed to generate TV (in the broader term, so including things like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs call them TCON-TV and TCON-LCD, which seems more appropriate. However, the mixers differ mostly by their capabilities, with some features being available only in the first one, or the number of planes they expose, but also through their register layout. And while the capabilities could be represented as properties, the register layout differences would need to express all the registers offsets as properties, which is usually quite bad. Especially since documentation on that hardware block is close to non-existent and we don't even have the list of all those registers in the first place. So let's call them mixer 0 and 1 in our compatibles, even though the name is pretty bad... At the moment, we only have tested the code on a board that has a single display output, so we're leaving the tcon-tv and mixer1 out. Reviewed-by:
-
Maxime Ripard authored
Some clocks and resets supposed to drive the LVDS logic in the display engine have been overlooked when the driver was first introduced. Add those additional resources to the binding, and we'll deal with the ABI stability in the code. Reviewed-by:
-
- 03 Jan, 2018 6 commits
-
-
David Lechner authored
This adds a new driver for Sitronix ST7735R display panels. This has been tested using an Adafruit 1.8" TFT. Signed-off-by:
David Lechner <david@lechnology.com> Reviewed-by:
-
David Lechner authored
This adds a new device tree binding for Sitronix ST7735R display panels, such as the Adafruit 1.8" TFT. Signed-off-by:
-
David Lechner authored
This adds a vendor prefix "jianda" for Jiandangjing Technology Co., Ltd. Signed-off-by:
-
David Lechner authored
This updates the compatible string for a no-name LCD panel to "vot,v220hf01a-t", "ilitek,ili9225". The original bindings were the generic "ilitek,ili9225-2.2in-176x220" because I could not find a datasheet. However, after some more research, I finally found one, so the actual vendor and model name are now known. This previous bindings have not made it to the mainline kernel yet, so this is not breaking backwards compatibility. Signed-off-by:
-
David Lechner authored
This updates the compatible string for a no-name LCD panel to "vot,v220hf01a-t", "ilitek,ili9225". The original bindings [1] were the generic "ilitek,ili9225-2.2in-176x220" because I could not find a datasheet. However, after some more research, I finally found one, so the actual vendor and model name are now known. This previous bindings have not made it to the mainline kernel yet, so this is not breaking backwards compatibility. This is also following the precedence of the ILI9322 bindings [2] by using the pattern "vendor,specific-system-config", "vendor,ip-part"; [1]: https://patchwork.ozlabs.org/patch/839352/ [2]: https://patchwork.ozlabs.org/patch/843576/Signed-off-by:
-
David Lechner authored
This adds a vendor prefix "vot" for Vision Optical Technology Co., Ltd. They make LCD displays. Signed-off-by:
-
- 23 Dec, 2017 1 commit
-
-
David Lechner authored
drm_panel_orientation_quirks.c introduced in commit 404d1a3e ("drm: Add panel orientation quirks, v6.") taints the kernel when compiled as a module. Fix this by adding MODULE_LICENSE(). Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 22 Dec, 2017 2 commits
-
-
Linus Walleij authored
This adds support for the Ilitek ILI9322 QVGA (320x240) TFT panel driver. This panel driver supports serial or parallel RGB or YUV input and also ITU-T BT.656 input streams. The controller is combined with a physical panel and configured through the device tree. Cc: David Lechner <david@lechnology.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Linus Walleij authored
This adds device tree bindings for the Ilitek ILI9322 320x240 TFT panel driver. Cc: David Lechner <david@lechnology.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Ben Dooks <ben.dooks@codethink.co.uk> Cc: devicetree@vger.kernel.org Reviewed-by:
-
- 20 Dec, 2017 6 commits
-
-
Maarten Lankhorst authored
This is is very useful to finding sources of leaked framebufers. The fbcon fb is annotated with [fbcon], to give it a better name than kworker. Signed-off-by:
-
Noralf Trønnes authored
Add helper for initializing fbdev deferred I/O. The cleanup could have happened in drm_fb_helper_fini(), but that would have required me to set fb_info->fbdefio to NULL in a couple of drivers before they call _fini() to avoid double defio cleanup. The problem is that one of those is vboxvideo which lives in Greg's staging tree. So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect but not that bad either. Signed-off-by:
-
Noralf Trønnes authored
Promote new helpers for dealing with fbdev emulation. Signed-off-by:
-
Noralf Trønnes authored
Add entry for conversion of drivers to new helpers. Signed-off-by:
-
Noralf Trønnes authored
Add helpers to setup and teardown fbdev emulation. Signed-off-by:
-
Noralf Trønnes authored
Set dev->fb_helper even when fbdev emulation is compiled out, so drivers can use it to free the structure. Clear it for consistency. Fixes: 29ad20b2 ("drm: Add drm_device->fb_helper pointer") Signed-off-by:
-
- 19 Dec, 2017 2 commits
-
-
Fabio Estevam authored
devm_ioremap_resource() already checks if the resource is NULL, so remove the unnecessary platform_get_resource() error check. Cc: Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Acked-by:
-
Fabio Estevam authored
devm_ioremap_resource() already checks if the resource is NULL, so remove the unnecessary platform_get_resource() error check. Cc: Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
-
- 15 Dec, 2017 5 commits
-
-
Daniel Vetter authored
We don't want people to accidentally stumble over there. Also rename the plane helpers to legacy plane helpers. After Ville's patch to make the clipping helper atomic and move it to drm_atomic_helper.c there's nothing left in there that should be useful for modern drivers. v2: Laurent had a few questions around how state is added to drm_atomic_state, tried to clarify that. And spotted another sentence where the docs suggested subclassing. v3: Small polish (Alex). Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171214203054.20141-6-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
DK put some nice docs into the commit introducing driver private state, but in the git history alone it'll be lost. Also, since Ville remove the void* usage it's a good opportunity to give the driver private stuff some tlc on the doc front. Finally try to explain why the "let's just subclass drm_atomic_state" approach wasn't the greatest, and annotate all those functions as deprecated in favour of more standardized driver private states. Also note where we could/should extend driver private states going forward (atm neither locking nor synchronization is handled in core/helpers, which isn't really all that great). v2: Spelling and phrasing improvements (Alex, DK). Cc: Harry Wentland <harry.wentland@amd.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Daniel Vetter authored
Complete a few missing bits, fix up the existing xcross-references and add a bunch more. v2: Fix typos (Alex). Cc: Dave Airlie <airlied@gmail.com> via lists.freedesktop.org Reviewed-by:
-
Daniel Vetter authored
It thinks we want to document the __printf(2,0) annotion. Not sure we want to teach it about all possible gcc-only flags, hence why I opted for the cheap trick of just moving it ahead of the kerneldoc. This is only a problem for static inline functions, since for non-inline function the kerneldoc is in the .c file, but the special annotations are all in the header. Cc'ing kernel-doc maintainers as fyi. Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Acked-by:
-
Daniel Vetter authored
Also some breadcrumbs for how exactly to find this. Probably should pass drm_connector * or at least drm_display_info * to that function instead. But drm_hdmi_avi_infoframe_quant_range probably also wants drm_connector_state (and the hdmi stuff moved into that), so this is a bit more work. v2: Fix typo (Alex). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 9271c0ca ("drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks") Acked-by:
-
- 14 Dec, 2017 1 commit
-
-
Thierry Reding authored
kerneldoc for drm_plane_create_zpos_property() says that the DRM core will automatically calculate the normalized zpos values, but it doesn't actually do that anymore since commit 38d868e4 ("drm: Don't force all planes to be added to the state due to zpos"). Instead, drivers are supposed to explicitly call the drm_atomic_normalize_zpos() function. Change the kerneldoc comment to reflect that. v2: reference the commit that introduced the kerneldoc unclarity Reviewed-by:
-
- 13 Dec, 2017 1 commit
-
-
Keith Packard authored
There are a set of values in the drm_display_info structure for each connector which hold information derived from EDID. These are computed in drm_add_display_info. Before this patch, that was only called in drm_add_edid_modes. This meant that they were only set when EDID was present and never reset when EDID was not, as happened when the display was disconnected. One of these fields, non_desktop, is used from drm_mode_connector_update_edid_property, the function responsible for assigning the new edid value to the application-visible property. Various drivers call these two functions (drm_add_edid_modes and drm_mode_connector_update_edid_property) in different orders. This means that even when EDID is present, the drm_display_info fields may not have been computed at the time that drm_mode_connector_update_edid_property used the non_desktop value to set the non_desktop property. I've added a public function (drm_reset_display_info) that resets the drm_display_info field values to default values and then made the drm_add_display_info function public. These two functions are now called directly from drm_mode_connector_update_edid_property so that the drm_display_info fields are always computed from the current EDID information before being used in that function. This means that the drm_display_info values are often computed twice, once when the EDID property it set and a second time when EDID is used to compute modes for the device. The alternative would be to uniformly ensure that the values were computed once before being used, which would require that all drivers reliably invoke the two paths in the same order. The computation is inexpensive enough that it seems more maintainable in the long term to simply compute them in both paths. The API to drm_add_display_info has been changed so that it no longer takes the set of edid-based quirks as a parameter. Rather, it now computes those quirks itself and returns them for further use by drm_add_edid_modes. This patch also includes a number of 'const' additions caused by drm_mode_connector_update_edid_property taking a 'const struct edid *' parameter and wanting to pass that along to drm_add_display_info. v2: after review by Daniel Vetter <daniel.vetter@ffwll.ch> Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and drm_add_display_info. Added FIXME in drm_mode_connector_update_edid_property about potentially merging that with drm_add_edid_modes to avoid the need for two driver calls. Signed-off-by:
Keith Packard <keithp@keithp.com> Reviewed-by:
-
