- 08 3月, 2018 2 次提交
-
-
由 Laurent Pinchart 提交于
The LVDS encoders used to be described in DT as part of the DU. They now have their own DT node, linked to the DU using the OF graph bindings. This allows moving internal LVDS encoder support to a separate driver modelled as a DRM bridge. Backward compatibility is retained as legacy DT is patched live to move to the new bindings. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
-
由 Laurent Pinchart 提交于
The internal LVDS encoders now have their own DT bindings. Before switching the driver infrastructure to those new bindings, implement backward-compatibility through live DT patching. Patching is disabled and will be enabled along with support for the new DT bindings in the DU driver. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: NFrank Rowand <frank.rowand@sony.com>
-
- 17 2月, 2018 1 次提交
-
-
由 Maxime Ripard 提交于
Commit eea034af ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata") broke the build with one build error and one warning. Fix both. Cc: Archit Taneja <architt@codeaurora.org> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Fixes: eea034af ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata") Reported-by: Nkbuild test robot <fengguang.wu@intel.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180216154412.22876-1-maxime.ripard@bootlin.com
-
- 16 2月, 2018 1 次提交
-
-
由 Jernej Skrabec 提交于
dw_hdmi shouldn't set drvdata since some drivers might need to store it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi instead to store it in drvdata. This way drivers are responsible to store and pass structure when needed. Idea was taken from the following commit: 8242ecbd ("drm/bridge/synopsys: stop clobbering drvdata") Cc: p.zabel@pengutronix.de Cc: Laurent.pinchart@ideasonboard.com Cc: hjc@rock-chips.com Acked-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NArchit Taneja <architt@codeaurora.org> Tested-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-6-jernej.skrabec@siol.net
-
- 15 2月, 2018 9 次提交
-
-
由 Sergei Shtylyov 提交于
After the recent corrections to the R-Car gen2/3 LVDS startup code, already similar enough at their ends rcar_lvds_enable_gen{2|3}() started asking for a merge and it's becoming actually necessary with the addition of the R-Car V3M (R8A77970) support -- this gen3 SoC has gen2-like LVDPLLCR layout. Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [Set the LVDS mode and input before turning channels on] [Rebased, coding style changes] Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Sergei Shtylyov 提交于
According to the latest revisions of the R-Car Gen3 manual, the LVDS mode must be set before the LVDS I/O pins are enabled, not after -- fix the Gen3 LVDS startup sequence accordingly. Fixes: e947eccb ("drm: rcar-du: Add support for LVDS mode selection") Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [Updated comment in rcar_du_lvdsenc_start_gen3()] [Moved Gen2 startup comment update to separate commit] [Fixed =| typo] Tested-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Sergei Shtylyov 提交于
According to the latest revision 2.00 of the R-Car Gen2 manual, the LVDS and the bias circuit must be enabled after the LVDS I/O pins are enabled, not before. Fix the Gen2 LVDS startup sequence accordingly. While at it, also fix the comment preceding the first LVDCR0 write that still talks about hardcoding the LVDS mode 0. Fixes: 90374b5c ("drm/rcar-du: Add internal LVDS encoder support") Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
According to the latest versions of both the Gen2 and Gen3 datasheets, the operating range for the LVDS clock is 31 MHz to 148.5 MHz on all SoCs. Update the driver accordingly. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
-
由 Sergei Shtylyov 提交于
The LVDCR1 register for the R-Car gen3 SoCs was documented as having the layout different from the gen2 SoCs in the early R-Car gen3 manuals but since v0.52 the LVDCR1 layout is described as being the same as on the gen2 SoCs; the old CHn control values are said to be prohibited now (and there seems to be no valid output signal when they are used). Fixes: 6bc2e15c ("drm: rcar-du: lvds: Add R-Car Gen3 support") Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
On Gen3 hardware the VSP compositor is required for display. Enable it by default in the kernel configuration. The option is kept user-configurable for testing purpose on Gen2 platforms. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Kuninori Morimoto 提交于
In general, PLL has VCO (= Voltage controlled oscillator), one of the very important electronic feature called as "jitter" is related to this VCO. In academic generalism, VCO should be maximum to be more small jitter. In high frequency clock, jitter will be large impact. Thus, selecting Hi VCO is general theory. fin fvco fout fclkout in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> out +-> | | | | | +-----------------[1/N]<-------------+ fclkout = fvco / P / FDPLL -- (1) In PD, it will loop until fin/M = fvco/P/N fvco = fin * P * N / M -- (2) (1) + (2) indicates fclkout = fin * N / M / FDPLL In this device, N = (n + 1), M = (m + 1), P = 2, FDPLL = (fdpll + 1). fclkout = fin * (n + 1) / (m + 1) / (fdpll + 1) This is the datasheet formula. One note here is that it should be 2kHz < fvco < 4096MHz To be smaller jitter, fvco should be maximum, in other words, N as large as possible, M as small as possible driver should select. Here, basically M=1. This patch do it. Reported-by: NHIROSHI INOSE <hiroshi.inose.rb@renesas.com> Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [Small clarifications in comments, renamed finnm to fout] Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Kuninori Morimoto 提交于
It is difficult to understand its scale if number has many 0s. This patch uses "* 1000" to avoid it in rcar_du_dpll_divider(). Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
Since commit 2fc4d838 ("drm: rcar: use generic code for managing zpos plane property") the rcar-du driver stores the plane zpos in the drm_plane_state structure. The commit however forgot to remove the zpos field from the rcar_du_vsp_plane_state structure. Remove it. Fixes: 2fc4d838 ("drm: rcar: use generic code for managing zpos plane property") Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 02 2月, 2018 1 次提交
-
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-1-ville.syrjala@linux.intel.comReviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
- 05 12月, 2017 1 次提交
-
-
由 Laurent Pinchart 提交于
Unlike the KMS API, the hardware doesn't support planes exceeding the screen boundaries or planes being located fully off-screen. We need to clip plane coordinates to support the use case. Fortunately the DRM core offers a drm_atomic_helper_check_plane_state() helper that validates the scaling factor and clips the plane coordinates. Use it to implement the plane atomic check and use the clipped source and destination rectangles from the plane state instead of the unclipped source and CRTC coordinates to configure the device. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
- 04 12月, 2017 6 次提交
-
-
由 Laurent Pinchart 提交于
The plane atomic check implementation is identical on Gen2 (DU planes) and Gen3 (VSP planes), but two separate functions exist as they operate on different data structures. Refactor the code to share the implementation. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Kieran Bingham 提交于
An early implementation of suspend-resume helpers are available in the CRTC module, however they are unused and no longer needed. With suspend and resume handled by the core DRM atomic helpers, we can remove the unused functions. Signed-off-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Kieran Bingham 提交于
To support system suspend operations we must ensure the hardware is stopped, and resumed explicitly from the suspend and resume handlers. Implement suspend and resume functions using the DRM atomic helper functions. Signed-off-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
Since commit 4a97a3da ("drm: Don't update property values for atomic drivers") atomic drivers must not update property values as properties are read from the state instead. To catch remaining users, the drm_object_property_set_value() function now throws a warning when called by atomic drivers on non-immutable properties, and we hit that warning when creating connectors. The easy fix is to just remove the drm_object_property_set_value() as it is used here to set the initial value of the connector's DPMS property to OFF. The DPMS property applies on top of the connector's state crtc pointer (initialized to NULL) that is the main connector on/off control, and should thus default to ON. Fixes: 4a97a3da ("drm: Don't update property values for atomic drivers") Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Fabrizio Castro 提交于
Add support for the R8A7745 DU (which is very similar to the R8A7794 DU); it has 2 RGB outputs. Signed-off-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: NBiju Das <biju.das@bp.renesas.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Fabrizio Castro 提交于
Add support for the R8A7743 DU (which is very similar to the R8A7791 DU); it has 1 DPAD (RGB) output and 1 LVDS output. Signed-off-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: NBiju Das <biju.das@bp.renesas.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
- 02 11月, 2017 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 01 10月, 2017 1 次提交
-
-
由 Noralf Trønnes 提交于
drm_fb_cma_create() is just a wrapper around drm_gem_fb_create() now, so use the function directly. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NNoralf Trønnes <noralf@tronnes.org> Reviewed-by: NEric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1506255985-61113-7-git-send-email-noralf@tronnes.org
-
- 08 8月, 2017 2 次提交
-
-
由 Daniel Vetter 提交于
It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over the panel/brideg refactorings in stm/ltdc. Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Peter Senna Tschudin <peter.senna@collabora.com> Cc: Martin Donnelly <martin.donnelly@ge.com> Cc: Martyn Welch <martyn.welch@collabora.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Stefan Agner <stefan@agner.ch> Cc: Alison Wang <alison.wang@freescale.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: CK Hu <ck.hu@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Marek Vasut <marex@denx.de> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Eric Anholt <eric@anholt.net> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Jeffy Chen <jeffy.chen@rock-chips.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Yakir Yang <kuankuan.y@gmail.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Romain Perier <romain.perier@collabora.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Hai Li <hali@codeaurora.org> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: nouveau@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-tegra@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Cc: zain wang <wzz@rock-chips.com> Cc: Baoyou Xie <baoyou.xie@linaro.org> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170725080122.20548-8-daniel.vetter@ffwll.chAcked-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de> Acked-by: NArchit Taneja <architt@codeaurora.org> Tested-by: Philippe Cornu <philippe.cornu@st.com> (on stm) Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: NShawn Guo <shawnguo@kernel.org> Acked-by: NShawn Guo <shawnguo@kernel.org> Acked-by: NNoralf Trønnes <noralf@tronnes.org> Acked-by: NVincent Abriou <vincent.abriou@st.com>
-
由 Daniel Vetter 提交于
It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_plane_set_property. Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Eric Engestrom <eric@engestrom.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rob Clark <robdclark@gmail.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170725080122.20548-6-daniel.vetter@ffwll.chReviewed-by: NArchit Taneja <architt@codeaurora.org> Acked-by: NPhilippe Cornu <philippe.cornu@st.com> Tested-by: NPhilippe Cornu <philippe.cornu@st.com> Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com> Acked-by: NVincent Abriou <vincent.abriou@st.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
- 03 8月, 2017 13 次提交
-
-
由 Maarten Lankhorst 提交于
for_each_obj_in_state is about to be removed, so use the correct new iterator macros. Also look at new_plane_state instead of plane->state when looking up the hw planes in use. They should be the same except when reallocating, (in which case this code is skipped) and we should really stop looking at obj->state whenever possible. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Kieran Bingham 提交于
The driver recently switched from handling page flip completion in the DU vertical blanking handler to the VSP frame end handler to fix a race condition. This unfortunately resulted in incorrect timestamps in the vertical blanking events sent to userspace as vertical blanking is now handled after sending the event. To fix this we must reverse the order of the two operations. The easiest way is to handle vertical blanking in the VSP frame end handler before sending the event. The VSP frame end interrupt occurs approximately 50µs earlier than the DU frame end interrupt, but this should not cause any undue harm. As we need to handle vertical blanking even when page flip completion is delayed, the VSP driver now needs to call the frame end completion callback unconditionally, with a new argument to report whether page flip has completed. With this new scheme the DU vertical blanking interrupt isn't needed anymore, so we can stop enabling it. Fixes: d503a43a ("drm: rcar-du: Register a completion callback with VSP1") Signed-off-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
-
由 Laurent Pinchart 提交于
When stopping the CRTC the driver must disable all planes and wait for the change to take effect at the next vblank. Merely calling drm_crtc_wait_one_vblank() is not enough, as the function doesn't include any mechanism to handle the race with vblank interrupts. Replace the drm_crtc_wait_one_vblank() call with a manual mechanism that handles the vblank interrupt race. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
Page flips can take more than one vertical blanking to complete if arming the page flips races with the vertical blanking interrupt. Waiting for one vblank to complete the atomic commit in the commit tail handler is thus incorrect, and can lead to framebuffers being released while still being scanned out. Fix this by waiting for flip completion instead, using the drm_atomic_helper_wait_for_flip_done() helper. Fixes: 0d230422d256 ("drm: rcar-du: Register a completion callback with VSP1") Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
When implementing support for interlaced modes, the driver switched from reporting vblank events on the vertical blanking (VBK) interrupt to the frame end interrupt (FRM). This incorrectly divided the reported refresh rate by two. Fix it by moving back to the VBK interrupt. Fixes: 906eff7f ("drm: rcar-du: Implement support for interlaced modes") Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
Update the device description with the HDMI output. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Dan Carpenter 提交于
"params" can't be NULL here. The next lines assume that we either hit the break statement of "params->mpixelclock == ~0UL". The inconsistent NULL checking makes static checkers complain. I've just removed the test. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
Commit 52055baf ("drm: rcar-du: Move plane commit code from CRTC start to CRTC resume") changed the order of the plane commit and CRTC enable operations to accommodate the runtime PM requirements. However, this introduced corruption in the first displayed frame, as the CRTC is now enabled without any plane configured. On Gen2 hardware the first frame will be black and likely unnoticed, but on Gen3 hardware we end up starting the display before the VSP compositor, which is more noticeable. To fix this, revert the order of the commit operations back, and handle runtime PM requirements in the CRTC .atomic_begin() and .atomic_enable() helper operation handlers. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
On Gen3 SoCs DPAD0 routing is configured through the last CRTC group, unlike on Gen2 where it is configured through the first CRTC group. Fix the driver accordingly. Fixes: 2427b303 ("drm: rcar-du: Add R8A7795 device support") Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The H3 ES1.x exhibits dot clock duty cycle stability issues. We can work around them by configuring the DPLL to twice the desired frequency, coupled with a /2 post-divider. This isn't needed on other SoCs and breaks HDMI output on M3-W for a currently unknown reason, so restrict the workaround to H3 ES1.x. From an implementation point of view, move work around handling outside of the rcar_du_dpll_divider() function by requesting a x2 DPLL output frequency explicitly. The existing post-divider calculation mechanism will then take care of dividing the clock by two automatically. While at it, print a more useful debugging message to ease debugging clock rate issues. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
On R-Car H3 ES2.0, DU channels 0 and 3 are served by two separate pipelines from the same VSP. Support this in the DU driver. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
To avoid mixing comment styles when new comments complying with the kernel coding style are introduced, fix all multiline comments in one go. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Kuninori Morimoto 提交于
Now, we can use of_graph_get_remote_endpoint(). Let's use it. Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
- 02 8月, 2017 1 次提交
-
-
由 Ben Widawsky 提交于
This is the plumbing for supporting fb modifiers on planes. Modifiers have already been introduced to some extent, but this series will extend this to allow querying modifiers per plane. Based on this, the client to enable optimal modifications for framebuffers. This patch simply allows the DRM drivers to initialize their list of supported modifiers upon initializing the plane. v2: A minor addition from Daniel v3: * Updated commit message * s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu) * Remove some excess newlines (Liviu) * Update comment for > 64 modifiers (Liviu) v4: Minor comment adjustments (Liviu) v5: Some new platforms added due to rebase v6: Add some missed plane inits (or maybe they're new - who knows at this point) (Daniel) Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: Daniel Stone <daniels@collabora.com> (v2) Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: NDaniel Stone <daniels@collabora.com>
-
- 30 7月, 2017 1 次提交
-
-
由 Laurent Pinchart 提交于
In the H3 ES2.0 SoC the VSP2-DL instance has two connections to DU channels that need to be configured independently. Extend the VSP-DU API with a pipeline index to identify which pipeline the caller wants to operate on. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
-