summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2020-09-07drm/vc4: crtc: Remove mode_set_nofbMaxime Ripard1-6/+1
On BCM2711 to avoid stale pixels getting stuck in intermediate FIFOs, the pixelvalve needs to be setup each time there's a mode change or enable / disable sequence. Therefore, we can't really use mode_set_nofb anymore to configure it, but we need to move it to atomic_enable. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/f86c7a6946f98262f1cf59a461596a796d4bcc5f.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: hvs: Make sure our channel is resetMaxime Ripard1-0/+4
In order to clear our intermediate FIFOs that might end up with a stale pixel, let's make sure our FIFO channel is reset every time our channel is setup. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/b34c562b36177c758dd2e9d84bceb07689bfbe05.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Move the HVS gamma LUT setup to our init functionMaxime Ripard4-47/+16
Since most of the HVS channel is setup in the init function, let's move the gamma setup there too. As this makes the HVS mode_set function empty, let's remove it in the process. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/d439da8f1592a450a6ad35ab1f9e77def17c7965.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Move HVS init and close to a functionMaxime Ripard1-46/+58
In order to make further refactoring easier, let's move the HVS channel setup / teardown to their own function. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/fb1b5299d1636ddce8340b51a80d51641839f83b.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Move PV dump to config_pvMaxime Ripard1-14/+12
Now that we only configure the PixelValve in vc4_crtc_config_pv, it doesn't really make much sense to dump its register content in its caller. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/c195af7d9e140a2a6db32992ee7e54071c6f94ba.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Turn pixelvalve reset into a functionMaxime Ripard1-7/+13
The driver resets the pixelvalve FIFO in a number of occurences without always using the same sequence. Since this will be critical for BCM2711, let's move that sequence to a function so that we are consistent. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/fb31003a9eee02c4b949556299ff41f0a113499a.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Disable color management for HVS5Maxime Ripard2-7/+12
The HVS5 uses different color matrices. Disable color management support for now. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/e528e2edf0a1be3930196d437e548114dd9fcf59.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Add HDMI1 encoder typeMaxime Ripard1-0/+1
The BCM2711 sports a second HDMI controller, so let's add that second HDMI encoder type. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/6ba56d2421a4ad59ce72178e8f37eacfbd72cb33.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Rename HDMI encoder type to HDMI0Maxime Ripard3-3/+3
The previous generations were only supporting a single HDMI controller, but that's about to change, so put an index as well to differentiate between the two controllers. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/84e11e4793aaa30d6e5c56e305d22404ac5a932d.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Add function to compute FIFO level bitsMaxime Ripard1-2/+10
The longer FIFOs in vc5 pixelvalves means that the FIFO full level doesn't fit in the original register field and that we also have a secondary field. In order to prepare for this, let's move the registers fill part to a helper function. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/e46a3823128af50c1c833de8fa9b95e9b86c2f66.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Add FIFO depth to vc4_crtc_dataMaxime Ripard2-3/+20
Not all pixelvalve FIFOs in vc5 have the same depth, so we need to add that to our vc4_crtc_data structure to be able to compute the fill level properly later on. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/7df3549c1bea9b0a27c784dc416bb9a831e4e18f.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Assign output to channel automaticallyMaxime Ripard6-26/+200
The HVS found in the BCM2711 has 6 outputs and 3 FIFOs, with each output being connected to a pixelvalve, and some muxing between the FIFOs and outputs. Any output cannot feed from any FIFO though, and they all have a bunch of constraints. In order to support this, let's store the possible FIFOs each output can be assigned to in the vc4_crtc_data, and use that information at atomic_check time to iterate over all the CRTCs enabled and assign them FIFOs. The channel assigned is then set in the vc4_crtc_state so that the rest of the driver can use it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/f9aba3814ef37156ff36f310118cdd3954dd3dc5.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: kms: Convert to for_each_new_crtc_stateMaxime Ripard1-4/+6
The vc4 atomic commit loop has an handrolled loop that is basically identical to for_each_new_crtc_state, let's convert it to that helper. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/a712d2b70aaee20379cfc52c2141aa2f6e2a9d5b.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Enable and disable the PV in atomic_enable / disableMaxime Ripard1-3/+7
The VIDEN bit in the pixelvalve currently being used to enable or disable the pixelvalve seems to not be enough in some situations, which whill end up with the pixelvalve stalling. In such a case, even re-enabling VIDEN doesn't bring it back and we need to clear the FIFO. This can only be done if the pixelvalve is disabled though. In order to overcome this, we can configure the pixelvalve during mode_set_no_fb by calling vc4_crtc_config_pv, but only enable it in atomic_enable and flush the FIFO there, and in atomic_disable disable the pixelvalve again. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/e97596f62f4df83424d994a23465463ac60f986e.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Use local chan variableMaxime Ripard1-1/+1
The vc4_crtc_handle_page_flip already has a local variable holding the value of vc4_crtc->channel, so let's use it instead. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/439c589baec72ddb89159857a2d078fdd77b02a2.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Rename HVS channel to outputMaxime Ripard4-8/+8
In vc5, the HVS has 6 outputs and 3 FIFOs (or channels), with pixelvalves each being assigned to a given output, but each output can then be muxed to feed from multiple FIFOs. Since vc4 had that entirely static, both were probably equivalent, but since that changes, let's rename hvs_channel to hvs_output in the vc4_crtc_data, since a pixelvalve is really connected to an output, and not to a FIFO. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/b7618bb17b1c435c5d6ce50bcde2fe9243281d02.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Move the cob allocation outside of bindMaxime Ripard2-20/+17
The COB allocation depends on the HVS channel used for a given pixelvalve. While the channel allocation was entirely static in vc4, vc5 changes that and at bind time, a pixelvalve can be assigned to multiple HVS channels. Let's prepare that rework by allocating the COB when it's actually needed. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/484cbd4b00cfeee425295df438222258cc39a3dd.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Use a shared interruptMaxime Ripard1-1/+3
Some pixelvalves in vc5 use the same interrupt line so let's register our interrupt handler as a shared one. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/5a915d374357f41083ac71779fa9b2c35a339c2f.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: crtc: Deal with different number of pixel per clockMaxime Ripard2-7/+14
Some of the HDMI pixelvalves in vc5 output two pixels per clock cycle. Let's put the number of pixel output per clock cycle in the CRTC data and update the various calculations to reflect that. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/18a3bb079981ba820132b37e736a4bb371234d2e.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: plane: Create more planesMaxime Ripard1-1/+1
Let's now create more planes that can be affected to all the CRTCs. vc4 has 3 CRTCs, 1 primary and 1 cursor each, and was having 24 (8 planes per CRTC) overlays. However, vc5 has 5 CRTCs, so keeping the same logic would put us at 50 planes which is well above the 32 planes limit imposed by DRM. Using 16 seems like a good tradeoff between staying under 32 and yet providing enough planes. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/b41003001541fc2bb23668c699c0369ff7983be8.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: plane: Optimize the LBM allocation sizeDave Stevenson1-4/+13
The current code is using the maximum of the source line size and the destination line size to compute the size of the LBM to allocate. While this is simpler, it starts to be an issue with modes such as 4k with a quite long that will consume all the available memory, so we no longer have that luxury. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://patchwork.freedesktop.org/patch/msgid/b9e091883a4f7395c5b6a4f7c6070225934293db.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: plane: Change LBM alignment constraint on LBMDave Stevenson1-1/+3
The HVS5 needs an alignment of 64bytes for its LBM memory, so let's reflect it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://patchwork.freedesktop.org/patch/msgid/6f9c4fe1eb9258a3f1d0f21af6a99c42472ac531.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: hvs: Boost the core clock during modesetMaxime Ripard3-0/+29
In order to prevent timeouts and stalls in the pipeline, the core clock needs to be maxed at 500MHz during a modeset on the BCM2711. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/37ed9e0124c5cce005ddc8dafe821d8b0da036ff.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/vc4: Add support for the BCM2711 HVS5Dave Stevenson4-59/+240
The HVS found in the BCM2711 is slightly different from the previous generations. Most notably, the display list layout changes a bit, the LBM doesn't have the same size and the formats ordering for some formats is swapped. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1d02fab3b916d639c2dc05608c117bbd8230ebe8.1599120059.git-series.maxime@cerno.tech
2020-09-07drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfsAngelo Ribeiro1-8/+90
Add support for the video pattern generator (VPG) BER pattern mode and configuration in runtime. This enables using the debugfs interface to manipulate the VPG after the pipeline is set. Also, enables the usage of the VPG BER pattern. Changes in v2: - Added VID_MODE_VPG_MODE - Solved incompatible return type on __get and __set Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Adrian Pop <pop.adrian61@gmail.com> Signed-off-by: Angelo Ribeiro <angelo.ribeiro@synopsys.com> Tested-by: Yannick Fertre <yannick.fertre@st.com> Tested-by: Adrian Pop <pop.adrian61@gmail.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Joao Pinto <jpinto@synopsys.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/a809feb7d7153a92e323416f744f1565e995da01.1586180592.git.angelo.ribeiro@synopsys.com
2020-09-07drm/bridge/synopsys: dsi: add support for non-continuous HS clockAntonio Borneo1-2/+7
Current code enables the HS clock when video mode is started or to send out a HS command, and disables the HS clock to send out a LP command. This is not what DSI spec specify. Enable HS clock either in command and in video mode. Set automatic HS clock management for panels and devices that support non-continuous HS clock. Signed-off-by: Antonio Borneo <antonio.borneo@st.com> Tested-by: Philippe Cornu <philippe.cornu@st.com> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701194234.18123-1-yannick.fertre@st.com
2020-09-07drm/bridge/synopsys: dsi: allow sending longer LP commandsAntonio Borneo1-8/+9
Current code does not properly computes the max length of LP commands that can be send during H or V sync, and rely on static values. Limiting the max LP length to 4 byte during the V-sync is overly conservative. Relax the limit and allows longer LP commands (16 bytes) to be sent during V-sync. Signed-off-by: Antonio Borneo <antonio.borneo@st.com> Tested-by: Philippe Cornu <philippe.cornu@st.com> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701143131.841-1-yannick.fertre@st.com
2020-09-07drm/bridge/synopsys: dsi: allow LP commands in video modeAntonio Borneo1-0/+8
Current code only sends LP commands in command mode. Allows sending LP commands also in video mode by setting the proper flag in DSI_VID_MODE_CFG. Signed-off-by: Antonio Borneo <antonio.borneo@st.com> Tested-by: Philippe Cornu <philippe.cornu@st.com> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708140836.32418-1-yannick.fertre@st.com
2020-09-06drm/panel: s6e63m0: Fix up DRM_DEV* regressionLinus Walleij3-27/+17
Ooops the panel drivers stopped to use DRM_DEV* messages and we predictably create errors by merging code that still use it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20200906132903.5739-1-linus.walleij@linaro.org
2020-09-05drm/panel: s6e63m0: Order enable/disable sequenceLinus Walleij1-3/+15
The upstream S6E63M0 driver has some peculiarities around the prepare/enable disable/unprepare sequence: the screen is taken out of sleep in prepare() as part of s6e63m0_init() the put to on with MIPI_DCS_SET_DISPLAY_ON in enable(). However it is just put into sleep mode directly in disable(). As disable()/enable() can be called without unprepare()/prepare() being called, this is unbalanced, we should take the display out of sleep in enable() then turn it off(). Further MIPI_DCS_SET_DISPLAY_OFF is never called balanced with MIPI_DCS_SET_DISPLAY_ON. The vendor driver for Samsung GT-I8190 (Golden) does all of these things in strict order. Augment the driver to do exit sleep/set display on in enable() and set display off/enter sleep in disable(). Further send an explicit reset pulse in power_on() so we come up in a known state, and issue the MCS_ERROR_CHECK command after setting display on like the vendor driver does. Also use the timings from the vendor driver in the sequence. Doing all of these things makes the display much more stable on the Samsung GT-I8190 when enabling/disabling the display pipeline. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Cc: Stephan Gerhold <stephan@gerhold.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200817213906.88207-1-linus.walleij@linaro.org
2020-09-05drm/panel: s6e63m0: Add code to identify panelLinus Walleij1-0/+60
We add code to identify a few different panels mounted on the s6e63m0 controller. This is necessary to achieve the proper biasing with DSI versions of the panel. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Stephan Gerhold <stephan@gerhold.net> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Acked-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200809215104.1830206-5-linus.walleij@linaro.org
2020-09-05drm/panel: s6e63m0: Add reading functionalityLinus Walleij4-2/+43
This adds code to send read commands to read a single byte from the display, in order to perform MTP ID look-up of the mounted panel on the s6e63m0 controller. This is needed for proper biasing on the DSI variants. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Stephan Gerhold <stephan@gerhold.net> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Acked-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200809215104.1830206-4-linus.walleij@linaro.org
2020-09-05drm/panel: s6e63m0: Add DSI transportLinus Walleij6-3/+144
This makes it possible to use the s6e63m0 panel with a DSI host, such as in the Samsung GT-I8190 (Golden) mobile phone. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Stephan Gerhold <stephan@gerhold.net> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Acked-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200809215104.1830206-3-linus.walleij@linaro.org
2020-09-05drm/panel: s6e63m0: Break out SPI transportLinus Walleij5-70/+124
This panel can be accessed using both SPI and DSI. To make it possible to probe and use the device also from a DSI bus, first break out the SPI support to its own file. Since all the panel driver does is write DCS commands to the panel, we pass a DCS write function to probe() from each subdriver. We make the Kconfig entry for SPI mode default so all current users will continue to work. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Stephan Gerhold <stephan@gerhold.net> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Acked-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/384873/
2020-09-03drm/managed: Cleanup of unused functions and polishing docsDaniel Vetter2-58/+22
Following functions are only used internally, not by drivers: - devm_drm_dev_init Also, now that we have a very slick and polished way to allocate a drm_device with devm_drm_dev_alloc, update all the docs to reflect the new reality. Mostly this consists of deleting old and misleading hints. Two main ones: - it is no longer required that the drm_device base class is first in the structure. devm_drm_dev_alloc can cope with it being anywhere - obviously embedded now strongly recommends using devm_drm_dev_alloc v2: Fix typos (Noralf) v3: Split out the removal of drm_dev_init, that's blocked on some discussions on how to convert vgem/vkms/i915-selftests. Adjust commit message to reflect that. Cc: Noralf Trønnes <noralf@tronnes.org> Acked-by: Noralf Trønnes <noralf@tronnes.org> (v2) Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Luben Tuikov <luben.tuikov@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200902072627.3617301-1-daniel.vetter@ffwll.ch
2020-09-03drm/ttm: remove io_reserve_lru handling v3Christian König4-169/+24
That is not used any more. v2: keep the NULL checks in TTM. v3: remove unused variable Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/388646/
2020-09-03drm/nouveau: move io_reserve_lru handling into the driver v5Christian König4-23/+127
While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve v3: rebased and use both base and offset in the check v4: fix small typos and test the patch v5: rebased and keep the mem.bus init in TTM. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/388643/
2020-09-03drm/ttm: make sure that we always zero init mem.bus v2Christian König1-0/+9
We are trying to remove the io_lru handling and depend on zero init base, offset and addr here. v2: init addr as well Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/388642/
2020-09-02drm/virtio: drop virtio_gpu_output->enabledGerd Hoffmann3-6/+1
Not needed, already tracked by drm_crtc_state->active. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200818072511.6745-3-kraxel@redhat.com
2020-09-02drm/virtio: fix unblankGerd Hoffmann3-1/+15
When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that. v2: use drm_atomic_crtc_needs_modeset() (Daniel). Cc: 1882851@bugs.launchpad.net Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Jiri Slaby <jirislaby@kernel.org> Tested-by: Diego Viola <diego.viola@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200818072511.6745-2-kraxel@redhat.com
2020-09-01drm/gma500: Constify static structsRikard Falkeborn1-3/+3
The only usage of these is to assign their address to the fbops field in the fb_info struct, which is a const pointer. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200830211741.17326-1-rikard.falkeborn@gmail.com
2020-09-01drm: Replace mode->export_head with a booleanVille Syrjälä1-13/+32
In order to shrink drm_display_mode below the magic two cacheline mark in 64bit we need to shrink it by another 8 bytes. The easiest thing to eliminate is the 'export_head' list head which is only used during the getconnector ioctl to temporarly track which modes on the connector's mode list are to be exposed and which are to remain hidden. We can simply replace the list head with a boolean which we use to tag the modes that are to be exposed. If we make sure to clear the tags after we're done with them we don't even need an extra loop over the modes to reset the tags at the start of the getconnector ioctl. Conveniently we already have a hole for the boolean left behind by the removal of mode->private_flags. The final size of the struct is now 112 bytes on 32bit and 120 bytes on 64bit. Another alternative would be a temp bitmask so we wouldn't have to have anything in the mode struct itself. The main issue is how large of a bitmask do we need? I guess we could allocate it dynamically but that means an extra kcalloc() and an extra loop through the modes to count them first (or grow the bitmask with krealloc() as needed). CC: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-17-ville.syrjala@linux.intel.com Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
2020-09-01drm/dp_mst: Support remote i2c writesSam McNally1-16/+90
For DP MST outputs, the i2c device currently only supports transfers that can be implemented using remote i2c reads. Such transfers must consist of zero or more write transactions followed by one read transaction. DDC/CI commands require standalone write transactions and hence aren't supported. Since each remote i2c write is handled as a separate transfer, remote i2c writes can support transfers consisting of write transactions, where all but the last have I2C_M_STOP set. According to the DDC/CI 1.1 standard, DDC/CI commands only require a single write or read transaction in a transfer, so this is sufficient. For i2c transfers meeting the above criteria, generate and send a remote i2c write message for each transaction. Add the trivial remote i2c write reply parsing support so remote i2c write acks bubble up correctly. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/37 Signed-off-by: Sam McNally <sammc@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200727160225.1.I4e95a534de051551cd143e6cb83d4c5a9b0ad1cd@changeid
2020-09-01drm/crc-debugfs: Fix memleak in crc_control_writeDinghao Liu1-1/+3
When verify_crc_source() fails, source needs to be freed. However, current code is returning directly and ends up leaking memory. Fixes: d5cc15a0c66e ("drm: crc: Introduce verify_crc_source callback") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [danvet: change Fixes: tag per Laurent's review] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200819082228.26847-1-dinghao.liu@zju.edu.cn
2020-08-31drm: virtio: fix kconfig dependency warningRandy Dunlap1-1/+1
Fix kconfig dependency warning by using a different Kconfig symbol. WARNING: unmet direct dependencies detected for VIRTIO_DMA_SHARED_BUFFER Depends on [n]: VIRTIO_MENU [=n] && DMA_SHARED_BUFFER [=y] Selected by [y]: - DRM_VIRTIO_GPU [=y] && HAS_IOMEM [=y] && DRM [=y] && VIRTIO [=y] && MMU [=y] Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: http://patchwork.freedesktop.org/patch/msgid/7481fb88-6b04-3726-57e0-0f513245c657@infradead.org Cc: David Airlie <airlied@linux.ie> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: virtualization@lists.linux-foundation.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-08-31drm/radeon/ttm: don't store driver copy of device pointer.Dave Airlie1-4/+4
This can be gotten back from bdev. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826014428.828392-3-airlied@gmail.com
2020-08-31drm/amdgpu/ttm: remove unused parameter to move blitDave Airlie1-4/+4
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826014428.828392-2-airlied@gmail.com
2020-08-31drm/hisilicon: Removed the dependency on the mmuTian Tao1-1/+1
hibmc can only be used in ARM64 architectures, and mmu defaults to y in arch/arm64/Kconfig, so there is no need to add a dependency on mmu in hibmc's kconfig. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1598428528-49046-1-git-send-email-tiantao6@hisilicon.com
2020-08-30drm/vkms: avoid warning in vkms_get_vblank_timestampSidong Yang1-0/+5
This patch avoid the warning in vkms_get_vblank_timestamp when vblanks aren't enabled. When running igt test kms_cursor_crc just after vkms module, the warning raised like below. Initial value of vblank time is zero and hrtimer.node.expires is also zero if vblank aren't enabled before. vkms module isn't real hardware but just virtual hardware module. so vkms can't generate a resonable timestamp when hrtimer is off. it's best to grab the current time. [106444.464503] [IGT] kms_cursor_crc: starting subtest pipe-A-cursor-size-change [106444.471475] WARNING: CPU: 0 PID: 10109 at vkms_get_vblank_timestamp+0x42/0x50 [vkms] [106444.471511] CPU: 0 PID: 10109 Comm: kms_cursor_crc Tainted: G W OE 5.9.0-rc1+ #6 [106444.471514] RIP: 0010:vkms_get_vblank_timestamp+0x42/0x50 [vkms] [106444.471528] Call Trace: [106444.471551] drm_get_last_vbltimestamp+0xb9/0xd0 [drm] [106444.471566] drm_reset_vblank_timestamp+0x63/0xe0 [drm] [106444.471579] drm_crtc_vblank_on+0x85/0x150 [drm] [106444.471582] vkms_crtc_atomic_enable+0xe/0x10 [vkms] [106444.471592] drm_atomic_helper_commit_modeset_enables+0x1db/0x230 [drm_kms_helper] [106444.471594] vkms_atomic_commit_tail+0x38/0xc0 [vkms] [106444.471601] commit_tail+0x97/0x130 [drm_kms_helper] [106444.471608] drm_atomic_helper_commit+0x117/0x140 [drm_kms_helper] [106444.471622] drm_atomic_commit+0x4a/0x50 [drm] [106444.471629] drm_atomic_helper_set_config+0x63/0xb0 [drm_kms_helper] [106444.471642] drm_mode_setcrtc+0x1d9/0x7b0 [drm] [106444.471654] ? drm_mode_getcrtc+0x1a0/0x1a0 [drm] [106444.471666] drm_ioctl_kernel+0xb6/0x100 [drm] [106444.471677] drm_ioctl+0x3ad/0x470 [drm] [106444.471688] ? drm_mode_getcrtc+0x1a0/0x1a0 [drm] [106444.471692] ? tomoyo_file_ioctl+0x19/0x20 [106444.471694] __x64_sys_ioctl+0x96/0xd0 [106444.471697] do_syscall_64+0x37/0x80 [106444.471699] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Melissa Wen <melissa.srw@gmail.com> Signed-off-by: Sidong Yang <realwakka@gmail.com> Reviewed-by: Melissa Wen <melissa.srw@gmail.com> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200828124553.2178-1-realwakka@gmail.com
2020-08-30drm/vkms: add alpha-premultiplied color blendingMelissa Wen1-16/+39
The VKMS blend function was ignoring the alpha channel and just overwriting vaddr_src with vaddr_dst. This XRGB approach triggers a warning when running the kms_cursor_crc/cursor-alpha-transparent test case. In IGT, cairo_format_argb32 uses premultiplied alpha (according to documentation). Also current DRM assumption is that alpha is premultiplied. Therefore, this patch considers premultiplied alpha blending eq to compose vaddr_src with vaddr_dst. This change removes the following cursor-alpha-transparent warning: "Suspicious CRC: All values are 0." V2: - static for local functions - const for the read-only variable argb_src - replaces variable names - drops unnecessary comment Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200825114532.abzdooluny2ekzvm@smtp.gmail.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-02-02 08:12:26 +0300