- 16 Dec, 2019 15 commits
-
-
Hans de Goede authored
Some options which can be specified on the commandline, such as margin_right=..., margin_left=..., etc. are applied not only to the specified mode, but to all modes. As such it would be nice if the user can simply say e.g. video=HDMI-1:margin_right=14,margin_left=24,margin_bottom=36,margin_top=42 This commit refactors drm_mode_parse_command_line_for_connector() to add support for this, and as a nice side effect also cleans up the function a bit. Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118155134.30468-8-hdegoede@redhat.com
-
Hans de Goede authored
drm_connector_get_cmdline_mode() calls drm_mode_parse_command_line_for_connector() with &connector->cmdline_mode as mode argument, so anything which we store in the mode arguments gets kept even if we return false. Avoid storing a possibly false-postive bpp/refresh_specified setting in connector->cmdline_mode by moving the setting of these to after successful parsing of the bpp/refresh parts of the video= argument. Acked-by:
-
Hans de Goede authored
Add a freestanding function argument to drm_mode_parse_cmdline_options() similar to how drm_mode_parse_cmdline_extra() already has this. This is a preparation patch for allowing parsing of stand-alone options without a mode before them, e.g.: video=HDMI-1:margin_right=14,... Acked-by:
-
Hans de Goede authored
Refactor drm_mode_parse_cmdline_options() so that it takes a pointer to the first option, rather then a pointer to the ',' before the first option. This is a preparation patch for allowing parsing of stand-alone options without a mode before them, e.g.: video=HDMI-1:margin_right=14,... Acked-by:
-
Hans de Goede authored
Before this commit it was impossible to combine an extra mode argument specified directly after the resolution with an option, e.g. video=HDMI-1:720x480e,rotate=180 would not work, either the "e" to force enable would need to be dropped or the ",rotate=180", otherwise the mode_option would not be accepted. This commit fixes this by setting parse_extras to true in this case, so that drm_mode_parse_cmdline_res_mode() parses the extra arguments directly after the resolution. Acked-by:
-
Hans de Goede authored
Before this commit it was impossible to add an extra mode argument after a bpp or refresh specifier, combined with an option, e.g. video=HDMI-1:720x480-24e,rotate=180 would not work, either the "e" to force enable would need to be dropped or the ",rotate=180", otherwise the mode_option would not be accepted. This commit fixes this by fixing the length calculation if extras_ptr is set to stop the extra parsing at the start of the options (stop at the ',' options_ptr points to). Acked-by:
-
Hans de Goede authored
We are not supposed to modify the passed in string, make char pointers used in drm_mode_parse_cmdline_options() const char * where possible. Acked-by:
-
Hans de Goede authored
Before this commit, if the last option of a video=... option is for example "rotate" without a "=<value>" after it then delim will point to the terminating 0 of the string, and value which is sets to <delim + 1> will point one position past the end of the string. This commit fixes this by enforcing that the contents of delim equals '=' as it should be for options which take a value, this check is done in a new drm_mode_parse_cmdline_int helper function which factors out the common integer parsing code for all the options which take an int. Acked-by:
-
Heiko Stuebner authored
Add the compatible and GRF definitions for the PX30 soc. changes in v5: - rebased on top of 5.5-rc1 - merged with dsi timing change to prevent ordering conflicts Signed-off-by:
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191209143130.4553-7-heiko@sntech.de
-
Heiko Stuebner authored
The px30 SoC also uses a dw-mipi-dsi controller, so add the compatible value for it. changes in v5: - rebased on top of 5.5-rc1 - merged with dsi timing change to prevent ordering conflicts Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191209143130.4553-6-heiko@sntech.de
-
Heiko Stuebner authored
While the common case is that the dsi controller uses an internal dphy, accessed through the phy registers inside the dsi controller, there is also the possibility to use a separate dphy from a different vendor. One such case is the Rockchip px30 that uses a Innosilicon Mipi dphy, so add the support for handling such a constellation, including the pll also getting generated inside that external phy. changes in v5: - rebased on top of 5.5-rc1 - merged with dsi timing change to prevent ordering conflicts Signed-off-by:
-
Heiko Stuebner authored
Some dw-mipi-dsi instances in Rockchip SoCs use external dphys. In these cases the needs clock will also be generated externally so these don't need the ref-clock as well. changes in v5: - rebased on top of 5.5-rc1 - merged with dsi timing change to prevent ordering conflicts Signed-off-by:
-
Heiko Stuebner authored
If implementation-specific phy_ops need to be defined they probably should be enabled before trying to talk to the panel and disabled only after the panel was disabled. Right now they are enabled last and disabled first, so might make it impossible to talk to some panels - example for this being the px30 with an external Innosilicon dphy that needs the phy to be enabled to transfer commands to the panel. So move the calls appropriately. changed in v5: - rebased on top of 5.5-rc1 - merged with dsi timing change to prevent ordering conflicts Signed-off-by:
Yannick Fertre <yannick.fertre@st.com> Reviewed-by:
Philippe Cornu <philippe.cornu@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191209143130.4553-3-heiko@sntech.de
-
Heiko Stuebner authored
The timing values for dw-dsi are often dependent on the used display and according to Philippe Cornu will most likely also depend on the used phy technology in the soc-specific implementation. To solve this and allow specific implementations to define them as needed add a new get_timing callback to phy_ops and call this from the dphy_timing function to retrieve the necessary values for the specific mode. Right now this handles the hs2lp + lp2hs where Rockchip SoCs need handling according to the phy speed, while STM seems to be ok with static values. changes in v5: - rebase on 5.5-rc1 - merge into px30 dsi series to prevent ordering conflicts changes in v4: - rebase to make it directly fit on top of drm-misc-next after all changes in v3: - check existence of phy_ops->get_timing in __dw_mipi_dsi_probe() - emit actual error when get_timing() call fails - add tags from Philippe and Yannick changes in v2: - add driver-specific handling, don't force all bridge users to use the same timings, as suggested by Philippe Suggested-by:
-
Jyri Sarha authored
Remove obsolete bundled tfp410 driver with its "ti,tilcdc,tfp410" devicetree binding. No platform has ever used this driver in the mainline kernel and if anybody connects tfp410 to tilcdc he or she should use the generic drm tfp410 bridge driver. Signed-off-by:
Jyri Sarha <jsarha@ti.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e2db6c328467cc51e8d633ecb0ffa7c5736f2e8.1575901747.git.jsarha@ti.com
-
- 14 Dec, 2019 8 commits
-
-
Paul Cercueil authored
The LCD controller in the JZ4770 supports up to 720p. While there has been many new features added since the old JZ4740, which are not yet handled here, this driver still works fine. v2: No change Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20191210144142.33143-6-paul@crapouillou.net # *** extracted tags *** Acked-by:
Sam Ravnborg <sam@ravnborg.org>
-
Paul Cercueil authored
Check that the requested display size isn't above the limits supported by the CRTC. - JZ4750 and older support up to 800x600; - JZ4755 supports up to 1024x576; - JZ4760 and JZ4770 support up to 720p; - JZ4780 supports up to 2k. v2: No change Signed-off-by:
-
Paul Cercueil authored
While the LCD controller can effectively only support a maximum resolution of 800x600, the framebuffer's height can be much higher, since we can change the Y start offset. v2: No change Signed-off-by:
-
Paul Cercueil authored
Instead of obtaining the width/height of the framebuffer from the CRTC state, obtain it from the current plane state. v2: No change Signed-off-by:
-
Paul Cercueil authored
It is possible that there is no drm_framebuffer associated with a given plane state. v2: Handle drm_plane->state which can be NULL too Signed-off-by:
-
Paul Cercueil authored
Add a compatible string for the LCD controller found in the JZ4770 SoC. v2: No change Signed-off-by:
-
zhengbin authored
Fixes coccicheck warning: drivers/gpu/drm/sun4i/sun4i_layer.c:253:3-4: Unneeded semicolon drivers/gpu/drm/sun4i/sun4i_layer.c:257:2-3: Unneeded semicolon Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
zhengbin <zhengbin13@huawei.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/1576317091-24968-3-git-send-email-zhengbin13@huawei.com
-
zhengbin authored
Fixes coccicheck warning: drivers/gpu/drm/sun4i/sun8i_mixer.c:289:3-4: Unneeded semicolon drivers/gpu/drm/sun4i/sun8i_mixer.c:292:2-3: Unneeded semicolon drivers/gpu/drm/sun4i/sun8i_mixer.c:302:3-4: Unneeded semicolon drivers/gpu/drm/sun4i/sun8i_mixer.c:305:2-3: Unneeded semicolon Reported-by:
-
- 13 Dec, 2019 5 commits
-
-
Linus Walleij authored
The GMA500 driver is using the legacy GPIO API to fetch three optional display control GPIO lines from the SFI description used by the Medfield platform. Switch this over to use GPIO descriptors and delete the custom platform data. We create three new static locals in the tc35876x bridge code but it is hardly any worse than the I2C client static local already there: I tried first to move it to the DRM driver state container but there are workarounds for probe order in the code so I just stayed off it, as the result is unpredictable. People wanting to do a more throrugh and proper cleanup of the GMA500 driver can work on top of this, I can't solve much more since I don't have access to the hardware, I can only attempt to tidy up my GPIO corner. Cc: Daniel Stone <daniels@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191206094301.76368-1-linus.walleij@linaro.orgSigned-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Daniel Vetter authored
Checking both is one too much, so wrap a WARN_ON around it to stope the copypasta. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
-
Jerry Han authored
Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI panel. V11: - Use the backlight support in drm_panel to simplify the driver (Sam) V10: - Adjust init code, make the format more concise (Emil) V9: - kill off default_off_cmds (Emil) - use mipi_dsi_dcs_set_display_{on,off} in their enable/disable callbacks. (Emil) - Adjusting the delay function (Emil) V8: - modify PARENTHESIS_ALIGNMENT format (Sam) - use gpios are required API replace optional gpio API (Emil) V7: - Modify communication address V6: - Add the information of the reviewer - Remove unnecessary delays, The udelay_range code gracefully returns without hitting the scheduler on a delay of 0. (Derek) - Merge the same data structures, like display_mode and off_cmds (Derek) - Optimize the processing of results returned by devm_gpiod_get_optional (Derek) V5: - Add the information of the reviewer (Sam) - Delete unnecessary header files #include <linux/fb.h> (Sam) - The config DRM_PANEL_BOE_HIMAX8279D appears twice. Drop one of them (Sam) - ADD static, set_gpios function is not used outside this module (Sam) V4: - Frefix all function maes with boe_ (Sam) - Fsed "enable_gpio" replace "reset_gpio", Make it look clearer (Sam) - Sort include lines alphabetically (Sam) - Fixed entries in the makefile must be sorted alphabetically (Sam) - Add send_mipi_cmds function to avoid duplicating the code (Sam) - Add the necessary delay(reset_delay_t5) between reset and sending the initialization command (Rock wang) V3: - Remove unnecessary delays in sending initialization commands (Jitao Shi) V2: - Use SPDX identifier (Sam) - Use necessary header files replace drmP.h (Sam) - Delete unnecessary header files #include <linux/err.h> (Sam) - Specifies a GPIOs array to control the reset timing, instead of reading "dsi-reset-sequence" data from DTS (Sam) - Delete backlight_disable() function when already disabled (Sam) - Use devm_of_find_backlight() replace of_find_backlight_by_node() (Sam) - Move the necessary data in the DTS to the current file, like porch, display_mode and Init code etc. (Sam) - Add compatible device "boe,himax8279d10p" (Sam) V1: - Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI panel. Signed-off-by:Jerry Han <jerry.han.hq@gmail.com> Reviewed-by:
Derek Basehore <dbasehore@chromium.org> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Reported-by:
kbuild test robot <lkp@intel.com> Cc: Jitao Shi <jitao.shi@mediatek.com> Cc: Rock wang <rock_wang@himax.com.cn> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> [fixed boe_panel_get_modes + backlight] Link: https://patchwork.freedesktop.org/patch/msgid/20191212115208.3878-1-jerry.han.hq@gmail.com
-
Daniel Vetter authored
globle, goblin, moblin? It's dead code, we lucked out. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jani Nikula authored
Now that the fbops member of struct fb_info is const, we can start making the ops const as well. Remove the redundant fbops assignments while at it. v2: - actually add const in vivid - fix typo (Christophe de Dinechin) Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Andy Walls <awalls@md.metrocast.net> Cc: linux-media@vger.kernel.org Cc: ivtv-devel@ivtvdriver.org Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
- 12 Dec, 2019 3 commits
-
-
D32 is simple version of D71, the difference is: - Only has one pipeline - Drop the periph block and merge it to GCU v2: Rebase. v3: Isolate the block counting fix to a new patch Signed-off-by:
James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Reviewed-by:
Mihail Atanassov <mihail.atanassov@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210084828.19664-3-james.qian.wang@arm.com
-
1. Drop komeda-CORE product id comparison and put it into the d71_identify 2. Update pipeline node DT-binding: (a). Skip the needless pipeline DT node. (b). Return fail if the essential pipeline DT node is missing. With these changes, for chips in same family no need to change the DT. v2: Rebase v3: Address Mihail's comments. Signed-off-by:
-
Per HW, d71->num_blocks includes reserved blocks but no PERIPH block, correct the block counting accordingly. D71 happens to only have one reserved block and periph block, which hides this counting error. Signed-off-by:
-
- 11 Dec, 2019 9 commits
-
-
Thomas Zimmermann authored
The remaining code in udl_fb.c is unused. Remove the file entirely. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Thomas Zimmermann authored
The only caller of udl_handle_damage() in the plane-update function in udl_modeset.c. Move udl_handle_damage() there. v2: * remove udl_fb.c in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
The udl driver stores the currently active framebuffer to know from where to accept damage updates. With the conversion to plane-state damage handling, this is not necessary any longer. The currently active framebuffer and damaged area are always stored in the plane state. Signed-off-by:
-
Thomas Zimmermann authored
The infrastruture for atomic modesetting allows us to use the generic code for dirty-FB and damage handling. Switch over udl and remove the driver's implementation. The simple-pipe's update function now picks up the primary plane's damage and updates a minimal region of the screen. Signed-off-by:
-
Thomas Zimmermann authored
The current default color depth of 24 bpp is not even supported by the driver. Being the native format for communicating with the adapter, 16 bpp is the correct choice. Signed-off-by:
-
Thomas Zimmermann authored
DPMS functionality is only used by the CRTC's enable and disable functions. Inline the code. The patch also adds symbolic constants for the blank register and constants; according to udlfb, which is a bit more detailed than DRM's udl. v3: * use symbolic constants for blank, according to udlfb driver Signed-off-by:
-
Thomas Zimmermann authored
We can use the generic suspend/resume helpers for atomic modesetting. Switch udl over. Signed-off-by:
-
Thomas Zimmermann authored
Udl has a single display pipeline with a primary plane; perfect for simple-pipe helpers. Convert it over. The old encoder and CRTC code becomes unused and obsolete. Exported formats for the primary plane are RGB565 and XRGB8888, with the latter being emulated. The 16-bit format is the default and what is used when communicating with the device. This patch enables atomic modesetting for udl devices. v3: * remove unused field crtc from struct udl_device * set crtc_state->no_vblank at beginning of enable() v2: * move suspend/resume changes into separate patch * remove non-atomic code Signed-off-by:
-
Thomas Zimmermann authored
To mimic simple-pipe, we initialize the connector before the rest of the display pipeline. v2: * remove unnecessary calls to drm_connector_{register,unregister}() Signed-off-by:
-
