- 16 Dec, 2019 18 commits
-
-
Hans de Goede authored
Instead of only setting mode->specified on false on an early exit and leaving e.g. mode->bpp_specified and mode->refresh_specified as is, lets be consistent and just zero out the entire passed in struct at the top of drm_mode_parse_command_line_for_connector() Changes in v3: -Drop "mode->specified = false;" line instead of the "return false;" (oops) This crasher was reported-by: kernel test robot <lkp@intel.com> 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-11-hdegoede@redhat.com
-
Hans de Goede authored
fb_get_options() will return fb_mode_option if no video=<connector-name> argument is present on the kernel commandline, so there is no need to also do this in drm_mode_parse_command_line_for_connector() as our only caller uses fb_get_options() to get the mode_option argument. Changes in v2: -Split out the changes dealing with the initialization of the mode struct into a separate patch Acked-by:
-
Hans de Goede authored
Sometimes we want to override a connector's panel_orientation from the kernel commandline. Either for testing and for special cases, e.g. a kiosk like setup which uses a TV mounted in portrait mode. Users can already specify a "rotate" option through a video= kernel cmdline option. But that only supports 0/180 degrees (see drm_client_modeset TODO) and only works for in kernel modeset clients, not for userspace kms users. The "panel-orientation" connector property OTOH does support 90/270 degrees as it leaves dealing with the rotation up to userspace and this does work for userspace kms clients (at least those which support this property). Changes in v2: -Add missing ':' after @panel_orientation (reported by kbuild test robot) BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83Acked-by:
-
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:
-
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 6 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:
-
