- 09 Jan, 2020 1 commit
-
-
Rob Clark authored
Signed-off-by:
Rob Clark <robdclark@chromium.org> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200108235356.918189-1-robdclark@gmail.com
-
- 08 Jan, 2020 11 commits
-
-
Miquel Raynal authored
Satoz is a Chinese TFT manufacturer. Website: http://www.sat-sz.com/English/index.htmlSigned-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Sam Ravnborg authored
There is an increasing number of new simple panels. Common for many of these simple panels are that they have one mandatory power-supply and some of them have backlight and / or an enable gpio. The binding file to describe these panels adds overhead that really do not add value. The binding are known and there is nothing gained from a dedicated binding file nor for any dedicated example. The following patch introduces a single panel-simple.yaml and converts two ampire bindings over to the new file. The conversion - if applied will have following effects: - The maintainer for the individual file will change There is no need for many different maintainers for a simple binding. We have the same situation with the panel-simple driver in the kernel. - The license will change to (GPL-2.0-only OR BSD-2-Clause) There is usually only a single line copied from the original file, a line that is often copied from a datasheet. This license change should be acceptable considered what little is copied. If the license change is not OK we can use a dedicated binding file in these cases. This is a follow-up on Rob's big patch converting a lot of panel bindings to individual files: "dt-bindings: display: Convert a bunch of panels to DT schema" https://patchwork.ozlabs.org/patch/1197683/ The objectives with one file for the relevant simple panels are: - Make it simpler to add bindings for simple panels - Keep the number of bindings file lower and thus easier to find a relevant file to copy from when adding new panels. - Keep the binding documentation for simple panels more consistent - Make it simpler to add support for new panels v3: - Whitespace fix (checkpatch) - Indent compatible (Rob h) - Indent comments to give compatible more visibility (Rob h) v2: - spelling fixes (imirkin via irc, Rob) - updated description (Rob) - list properires in alphabetical order - added power-supply to example (Rob) - updated title - reworded changelog a little Signed-off-by: -
Dan Carpenter authored
We moved this code to a different file and accidentally deleted a newline. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200108054312.yzlj5wmbdktejgob@kili.mountain
-
Wambui Karuga authored
Since the if statement only checks for the value of the `id` variable, it can be replaced by the more concise BUG_ON() macro for error reporting. Issue found using coccinelle. Signed-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
Casting a pointer to dma_addr_t produces a warning: drivers/gpu/drm/meson/meson_rdma.c: In function 'meson_rdma_free': drivers/gpu/drm/meson/meson_rdma.c:59:25: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] priv->rdma.addr_phys = (dma_addr_t)NULL; In this case, it's worse because the variable name has the suffix '_phys', which often indicates a phys_addr_t rather than dma_addr_t, i.e. yet another incompatible type. Change it to use consistent naming and avoid NULL. Fixes: 63fba242 ("drm/meson: add RDMA module driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Chen Zhou authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/gma500/psb_irq.c: In function psb_irq_turn_off_dpst: drivers/gpu/drm/gma500/psb_irq.c:473:6: warning: variable hist_reg set but not used [-Wunused-but-set-variable] Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Chen Zhou <chenzhou10@huawei.com> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191227114811.14907-1-chenzhou10@huawei.com
-
Maxime Ripard authored
The DRC needs to run at 300MHz to be functional. This was done so far using assigned-clocks in the device tree, but that is easy to forget, and doesn't provide any other guarantee than the rate is going to be roughly the one requested at probe time. Therefore it's pretty fragile, so let's just use the exclusive clock API to enforce it. Reviewed-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200107165957.672435-2-maxime@cerno.tech
-
Maxime Ripard authored
The backend needs to run at 300MHz to be functional. This was done so far using assigned-clocks in the device tree, but that is easy to forget, and doesn't provide any other guarantee than the rate is going to be roughly the one requested at probe time. Therefore it's pretty fragile, so let's just use the exclusive clock API to enforce it. Reviewed-by:
-
Boris Brezillon authored
Commit 05193dc3 ("drm/bridge: Make the bridge chain a double-linked list") patched the bridge chain logic to use a double-linked list instead of a single-linked list. This change induced changes to the Exynos driver which was manually resetting the encoder->bridge element to NULL to control the enable/disable sequence of the bridge chain. During this conversion, 2 bugs were introduced: 1/ list_splice() was used to move chain elements to our own internal chain, but list_splice() does not reset the source list to an empty state, leading to unexpected bridge hook calls when drm_bridge_chain_xxx() helpers were called by the core. Replacing the list_splice() call by list_splice_init() fixes this problem. 2/ drm_bridge_chain_xxx() helpers operate on the bridge->encoder->bridge_chain list, which is now empty. When the helper uses list_for_each_entry_reverse() we end up with no operation done which is not what we want. But that's even worse when the helper uses list_for_each_entry_from(), because in that case we end up in an infinite loop searching for the list head element which is no longer encoder->bridge_chain but exynos_dsi->bridge_chain. To address that problem we stop using the bridge chain helpers and call the hooks directly. Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Fixes: 05193dc3 ("drm/bridge: Make the bridge chain a double-linked list") Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Tested-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191227144124.210294-3-boris.brezillon@collabora.com
-
Boris Brezillon authored
Commit 05193dc3 ("drm/bridge: Make the bridge chain a double-linked list") patched the bridge chain logic to use a double-linked list instead of a single-linked list. This change induced changes to the VC4 driver which was manually resetting the encoder->bridge element to NULL to control the enable/disable sequence of the bridge chain. During this conversion, 2 bugs were introduced: 1/ list_splice() was used to move chain elements to our own internal chain, but list_splice() does not reset the source list to an empty state, leading to unexpected bridge hook calls when drm_bridge_chain_xxx() helpers were called by the core. Replacing those list_splice() calls by list_splice_init() ones fixes this problem. 2/ drm_bridge_chain_xxx() helpers operate on the bridge->encoder->bridge_chain list, which is now empty. When the helper uses list_for_each_entry_reverse() we end up with no operation done which is not what we want. But that's even worse when the helper uses list_for_each_entry_from(), because in that case we end up in an infinite loop searching for the list head element which is no longer encoder->bridge_chain but vc4_dsi->bridge_chain. To address that problem we stop using the bridge chain helpers and call the hooks directly. Reported-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20191227144124.210294-2-boris.brezillon@collabora.com
-
kbuild test robot authored
Remove dev_err() messages after platform_get_irq*() failures. Line 450 is redundant because platform_get_irq() already prints an error. Generated by: scripts/coccinelle/api/platform_get_irq.cocci Fixes: dd90e9ae ("video: fbdev: mmp: add COMPILE_TEST support") Signed-off-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Julia Lawall <julia.lawall@inria.fr> Signed-off-by:
-
- 07 Jan, 2020 20 commits
-
-
Boris Brezillon authored
This reverts commit 6ed7e962 ("drm/bridge: Add a drm_bridge_state object") which introduced a circular dependency between drm.ko and drm_kms_helper.ko. Looks like the helper/core split is not appropriate and fixing that is not simple. Signed-off-by:
-
Boris Brezillon authored
This reverts commit f7619a58 ("drm/bridge: Patch atomic hooks to take a drm_bridge_state"). Commit 6ed7e962 ("drm/bridge: Add a drm_bridge_state object") introduced a circular dependency between drm.ko and drm_kms_helper.ko which uncovered a misdesign in how the whole thing was implemented. Let's revert all patches depending on the bridge_state infrastructure for now. Signed-off-by:
-
Boris Brezillon authored
This reverts commit b86d8955 ("drm/bridge: Add an ->atomic_check() hook"). Commit 6ed7e962 ("drm/bridge: Add a drm_bridge_state object") introduced a circular dependency between drm.ko and drm_kms_helper.ko which uncovered a misdesign in how the whole thing was implemented. Let's revert all patches depending on the bridge_state infrastructure for now. Signed-off-by:
-
Boris Brezillon authored
This reverts commit e351e4d5 ("drm/bridge: Add the necessary bits to support bus format negotiation"). Commit 6ed7e962 ("drm/bridge: Add a drm_bridge_state object") introduced a circular dependency between drm.ko and drm_kms_helper.ko which uncovered a misdesign in how the whole thing was implemented. Let's revert all patches depending on the bridge_state infrastructure for now. Signed-off-by:
-
Boris Brezillon authored
This reverts commit b18398c1 ("drm/bridge: Fix a NULL pointer dereference in drm_atomic_bridge_chain_check()"). Commit 6ed7e962 ("drm/bridge: Add a drm_bridge_state object") introduced a circular dependency between drm.ko and drm_kms_helper.ko which uncovered a misdesign in how the whole thing was implemented. Let's revert all patches depending on the bridge_state infrastructure for now. Signed-off-by:
-
Dingchen Zhang authored
to terminate the while-loop in drm_dp_aux_crc_work when drm_dp_start/stop_crc are called in the hook to set crc source. v3: set crc->opened to false without checking (Nick) v2: Move spin_lock around entire crc->opened use (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Harry Wentland <Harry.Wentland@amd.com> Cc: Nick Kazlauskas <Nicholas.Kazlauskas@amd.com> Signed-off-by:
Dingchen Zhang <dingchen.zhang@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190726173743.11641-1-dingchen.zhang@amd.com
-
Dingchen Zhang authored
userspace may transfer a newline, and this terminating newline is replaced by a '\0' to avoid followup issues. 'len-1' is the index to replace the newline of CRC source name. v3: typo fix (Sam) v2: update patch subject, body and format. (Sam) Cc: Leo Li <sunpeng.li@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Andrzej Pietrasiewicz authored
Use the ddc pointer provided by the generic connector. Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@collabora.com> Acked-by:
Emil Velikov <emil.velikov@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200102132300.24309-5-andrzej.p@collabora.com
-
Andrzej Pietrasiewicz authored
Use the ddc pointer provided by the generic connector. Signed-off-by:
-
Andrzej Pietrasiewicz authored
Use the ddc pointer provided by the generic connector. Signed-off-by:
-
Andrzej Pietrasiewicz authored
Use the ddc pointer provided by the generic connector. Signed-off-by:
-
Boris Brezillon authored
drm_atomic_bridge_chain_check() callers can pass a NULL bridge. Let's bail out before dereferencing the bridge pointer when that happens. Reported-by:
Chris Wilson <chris@chris-wilson.co.uk> Fixes: b86d8955 ("drm/bridge: Add an ->atomic_check() hook") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Thomas Zimmermann authored
For hardware that does not interpret the startadd field correctly, add the module parameter 'hw_bug_no_startadd', which enables the workaround. v3: * style and typo fixes v2: * ask user for feedback if the option is active Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Thomas Zimmermann authored
Drivers that what to allocate VRAM GEM objects with additional fields can now do this by implementing struct drm_driver.gem_create_object. v3: * separately check allocation failure in if/else branches before upcast to gbo v2: * only cast to gbo within if branch; set gbo directly in else branch Signed-off-by:
-
Thomas Zimmermann authored
TTM is an implementation detail of the VRAM helpers and therefore shouldn't be exposed to the callers. There's only one correct value for the BO device anyway, which is the one stored in the DRM device. So remove struct ttm_bo_device from the VRAM-helper interface and use the device's VRAM manager unconditionally. The GEM initializer function fails if the VRAM manager has not been initialized. Signed-off-by:
-
Thomas Zimmermann authored
The flag 'interruptible', which is passed to various functions, is always set to be false. Remove it and hard-code the value. Signed-off-by:
Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
-
Boris Brezillon authored
drm_bridge_state is extended to describe the input and output bus configurations. These bus configurations are exposed through the drm_bus_cfg struct which encodes the configuration of a physical bus between two components in an output pipeline, usually between two bridges, an encoder and a bridge, or a bridge and a connector. The bus configuration is stored in drm_bridge_state separately for the input and output buses, as seen from the point of view of each bridge. The bus configuration of a bridge output is usually identical to the configuration of the next bridge's input, but may differ if the signals are modified between the two bridges, for instance by an inverter on the board. The input and output configurations of a bridge may differ if the bridge modifies the signals internally, for instance by performing format conversion, or*modifying signals polarities. Bus format negotiation is automated by the core, drivers just have to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they want to take part to this negotiation. Negotiation happens in reverse order, starting from the last element of the chain (the one directly connected to the display) up to the first element of the chain (the one connected to the encoder). During this negotiation all supported formats are tested until we find one that works, meaning that the formats array should be in decreasing preference order (assuming the driver has a preference order). Note that the bus format negotiation works even if some elements in the chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks. In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets the previous bridge element decide what to do (most of the time, bridge drivers will pick a default bus format or extract this piece of information from somewhere else, like a FW property). Signed-off-by:Jonas Karlman <jonas@kwiboo.se> [narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format] Link: https://patchwork.freedesktop.org/patch/msgid/20200106143409.32321-5-narmstrong@baylibre.com
-
Boris Brezillon authored
So that bridge drivers have a way to check/reject an atomic operation. The drm_atomic_bridge_chain_check() (which is just a wrapper around the ->atomic_check() hook) is called in place of drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented, the core falls back on ->mode_fixup(), so the behavior should stay the same for existing bridge drivers). Signed-off-by:
-
Boris Brezillon authored
This way the drm_bridge_funcs interface is consistent with the rest of the subsystem. The only driver implementing those hooks (analogix DP) is patched too. Signed-off-by:
-
Boris Brezillon authored
One of the last remaining objects to not have its atomic state. This is being motivated by our attempt to support runtime bus-format negotiation between elements of the bridge chain. This patch just paves the road for such a feature by adding a new drm_bridge_state object inheriting from drm_private_obj so we can re-use some of the existing state initialization/tracking logic. Signed-off-by:
-
- 06 Jan, 2020 8 commits
-
-
Claudiu Beznea authored
This reverts commit d2c755e66617620b729041c625a6396c81d1231c ("drm: atmel-hlcdc: enable sys_clk during initalization."). With commit "drm: atmel-hlcdc: enable clock before configuring timing engine" there is no need for this patch. Code is also simpler. Cc: Sandeep Sheriker Mallikarjun <sandeepsheriker.mallikarjun@microchip.com> Signed-off-by:Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by:
-
Peter Rosin authored
The intention was to only select a higher pixel-clock rate than the requested, if a slight overclocking would result in a rate significantly closer to the requested rate than if the conservative lower pixel-clock rate is selected. The fixed patch has the logic the other way around and actually prefers the higher frequency. Fix that. Signed-off-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
Claudiu Beznea authored
Changing pixel clock source without having this clock source enabled will block the timing engine and the next operations after (in this case setting ATMEL_HLCDC_CFG(5) settings in atmel_hlcdc_crtc_mode_set_nofb() will fail). It is recomended (although in datasheet this is not present) to actually enabled pixel clock source before doing any changes on timing enginge (only SAM9X60 datasheet specifies that the peripheral clock and pixel clock must be enabled before using LCD controller). Fixes: 1a396789 ("drm: add Atmel HLCDC Display Controller support") Signed-off-by:
-
Claudiu Beznea authored
Doubled system clock should be used as pixel cock source only if this is supported. This is emphasized by the value of atmel_hlcdc_crtc::dc::desc::fixed_clksrc. Fixes: a6eca2ab ("drm: atmel-hlcdc: add config option for clock selection") Signed-off-by:
-
Sam Ravnborg authored
The reg property in the example caused following warnings: xinpeng,xpp055c272.example.dts:20.17-27: Warning (reg_format): /example-0/dsi@ff450000/panel@0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) xinpeng,xpp055c272.example.dt.yaml: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' xinpeng,xpp055c272.example.dt.yaml: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' xinpeng,xpp055c272.example.dt.yaml: Warning (spi_bus_reg): Failed prerequisite 'reg_format' xinpeng,xpp055c272.example.dts:18.21-24.15: Warning (avoid_default_addr_size): /example-0/dsi@ff450000/panel@0: Relying on default #address-cells value xinpeng,xpp055c272.example.dts:18.21-24.15: Warning (avoid_default_addr_size): /example-0/dsi@ff450000/panel@0: Relying on default #size-cells value Added #address-cells and #size-cells to silence the warning. Signed-off-by:
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Rob Herring <robh@kernel.org> Cc: devicetree@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200106181731.GA24294@ravnborg.org
-
yu kuai authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/bridge/cdns-dsi.c: In function ‘cdns_dsi_mode2cfg’: drivers/gpu/drm/bridge/cdns-dsi.c:515:11: warning: variable ‘nlanes’ set but not used [-Wunused-but-set-variable] It is never used, and so can be removed. Signed-off-by:
yu kuai <yukuai3@huawei.com> Reviewed-by:
-
yu kuai authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/bridge/cdns-dsi.c: In function ‘cdns_dsi_bridge_enable’: drivers/gpu/drm/bridge/cdns-dsi.c:788:6: warning: variable ‘bpp’ set but not used [-Wunused-but-set-variable] It is never used, and so can be removed. Signed-off-by:
-
zhengbin authored
Fixes coccicheck warning: drivers/gpu/drm/meson/meson_crtc.c:360:3-4: Unneeded semicolon drivers/gpu/drm/meson/meson_plane.c:181:2-3: Unneeded semicolon Reported-by:
zhengbin <zhengbin13@huawei.com> Reviewed-by:
-
