- 08 Sep, 2020 12 commits
-
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. The via_suspend() is designed to function only in the case of Suspend. Thus, the code checked for "if (state.event != PM_EVENT_SUSPEND)". This is because, in the legacy framework, this callback was invoked even in the event of Freeze and Hibernate. Hence, added the load of unnecessary function-calls. The goal can be achieved by binding the callback with only "via_pm_ops.suspend" in the new framework. This also avoids the step of checking "if (state.event != PM_EVENT_SUSPEND)" every time the callback is invoked. Signed-off-by:
Vaibhav Gupta <vaibhavgupta40@gmail.com> Cc: Bjorn Helgaas <helgaas@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Bjorn Helgaas <bjorn@helgaas.com> Cc: Vaibhav Gupta <vaibhav.varodek@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Andres Salomon <dilinger@queued.net> CC: Antonino Daplas <adaplas@gmail.com> Cc: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200819185654.151170-4-vaibhavgupta40@gmail.com
-
Vaibhav Gupta authored
Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. This way we can remove the legacy .suspend & .resume bindings from "lxfb_driver". The lxfb_suspend() is designed to function only in the case of Suspend. Thus, the code was kept inside "if (state.event == PM_EVENT_SUSPEND)" container. This is because, in the legacy framework, this callback was invoked even in the event of Freeze and Hibernate. Hence, added the load of unnecessary function-calls. The goal can be achieved by binding the callback with only "lxfb_pm_ops.suspend" in the new framework. This also avoids the step of checking "if (state.event == PM_EVENT_SUSPEND)" every time the callback is invoked. Signed-off-by:
-
Vaibhav Gupta authored
Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. This way we can remove the legacy .suspend & .resume bindings from "gxfb_driver". The gxfb_suspend() is designed to function only in the case of Suspend. Thus, the code was kept inside "if (state.event == PM_EVENT_SUSPEND)" container. This is because, in the legacy framework, this callback was invoked even in the event of Freeze and Hibernate. Hence, added the load of unnecessary function-calls. The goal can be achieved by binding the callback with only "gxfb_pm_ops.suspend" in the new framework. This also avoids the step of checking "if (state.event == PM_EVENT_SUSPEND)" every time the callback is invoked. Signed-off-by:
-
Tom Rix authored
Clang static analysis reports this representative error init.c:2501:18: warning: Array access (from variable 'queuedata') results in a null pointer dereference templ |= ((queuedata[i] & 0xc0) << 3); This is the problem block of code if(ModeNo > 0x13) { ... if(SiS_Pr->ChipType == SIS_730) { queuedata = &FQBQData730[0]; } else { queuedata = &FQBQData[0]; } } else { } queuedata is not set in the else block Reviewing the old code, the arrays FQBQData730 and FQBQData were used directly. So hoist the setting of queuedata out of the if-else block. Fixes: 544393fe ("[PATCH] sisfb update") Signed-off-by:Tom Rix <trix@redhat.com> Cc: Thomas Winischhofer <thomas@winischhofer.net> Cc: Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a pr_err message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Rodrigo Alencar authored
This patch provides support for displays like VGM128064B0W10, which requires a column offset of 2, i.e., its segments starts in SEG2 and ends in SEG129. Signed-off-by:
Rodrigo Alencar <455.rodrigo.alencar@gmail.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Colin Ian King authored
The pixclock is being set locally because it is being passed as a pass-by-value argument rather than pass-by-reference, so the computed pixclock is never being set in var->pixclock. Fix this by passing by reference. [This dates back to 2002, I found the offending commit from the git history git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git ] Addresses-Coverity: ("Unused value") Signed-off-by:
-
Evgeny Novikov authored
smtcfb_pci_probe() does not handle ioremap() errors for case 0x720. The patch fixes that exactly like for case 0x710/2. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Evgeny Novikov <novikov@ispras.ru> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: Teddy Wang <teddy.wang@siliconmotion.com> Signed-off-by:
-
George Kennedy authored
A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting or yres setting in struct fb_var_screeninfo will result in a KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as the margins are being cleared. The margins are cleared in chunks and if the xres setting or yres setting is a value of zero upto the chunk size, the failure will occur. Add a margin check to validate xres and yres settings. Signed-off-by:
George Kennedy <george.kennedy@oracle.com> Reported-by: syzbot+e5fd3e65515b48c02a30@syzkaller.appspotmail.com Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Dhaval Giani <dhaval.giani@oracle.com> Signed-off-by:
-
Christian König authored
This is used by TTM to communicate the physical address which should be used with ioremap(), ioremap_wc(). We don't need to separate the base and offset in any way here. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/389457/
-
Christian König authored
This is internal to TTM and should not be used by drivers directly. Drop the call to qxl_ttm_io_mem_reserve() and use mem->start instead. Signed-off-by:
-
Neil Armstrong authored
This fixes the following warnings while building in W=1 : dw-mipi-dsi.c:1002:5: warning: no previous prototype for 'dw_mipi_dsi_debugfs_write' [-Wmissing-prototypes] dw-mipi-dsi.c:1027:5: warning: no previous prototype for 'dw_mipi_dsi_debugfs_show' [-Wmissing-prototypes] Fixes: e2435d69 ("drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Angelo Ribeiro <angelo.ribeiro@synopsys.com> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200907102711.23748-1-narmstrong@baylibre.com
-
- 07 Sep, 2020 28 commits
-
-
Rodrigo Siqueira authored
This patch implements the necessary functions to add writeback support for vkms. This feature is useful for testing compositors if you don't have hardware with writeback support. Change in V4 (Emil and Melissa): - Move signal completion above drm_crtc_add_crc_entry() - Make writeback always available - Use appropriate namespace - Drop fb check in vkms_wb_atomic_commit - Make vkms_set_composer visible for writeback code - Enable composer operation on prepare_job and disable it on cleanup_job - Drop extra space at the end of the file - Rebase Change in V3 (Daniel): - If writeback is enabled, compose everything into the writeback buffer instead of CRC private buffer - Guarantees that the CRC will match exactly what we have in the writeback buffer. Change in V2: - Rework signal completion (Brian) - Integrates writeback with active_planes (Daniel) - Compose cursor (Daniel) Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200830142000.146706-4-rodrigosiqueiramelo@gmail.com
-
Rodrigo Siqueira authored
This commit decouples pixel manipulation from compute_crc() for avoiding any pixel change during the CRC calculation. This commits represents a preparation work for making VKMS able to support the writeback feature. Change in V5 (Melissa): - Rebase and drop bitmap for alpha Change in V4 (Emil): - Move bitmap_clear operation and comments to get_pixel function Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200830142000.146706-3-rodrigosiqueiramelo@gmail.com
-
Rodrigo Siqueira authored
In the vkms_composer.c, some of the functions related to CRC and compose have interdependence between each other. This patch reworks some functions inside vkms_composer to make crc and composer computation decoupled. This patch is preparation work for making vkms able to support new features. Tested-by:
-
Dave Airlie authored
I want to split this structure up and use it differently, step one remove bdev pointer from it and pass it explicitly. Reviewed-by:
-
Maxime Ripard authored
The BCM2711 has a reworked display pipeline, and the load tracker needs some adjustment to operate properly. Let's add a compatible for BCM2711 and disable the load tracker until properly supported. 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/beac4f9ef0261bca731a0402c8354e9af740519c.1599120059.git-series.maxime@cerno.tech
-
Maxime Ripard authored
The BCM2711 comes with a new VideoCore. Add a compatible for it. Signed-off-by:
Rob Herring <robh+dt@kernel.org> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1075091c50b378505a9a89f760af11f0e1e26e5b.1599120059.git-series.maxime@cerno.tech
-
Maxime Ripard authored
The HDMI controllers found in the BCM2711 SoC need some adjustments to the bindings, especially since the registers have been shuffled around in more register ranges. Signed-off-by:
-
Maxime Ripard authored
Now that the driver is ready for it, let's bring in the HDMI controllers variants for the BCM2711. Signed-off-by:
-
Hoegeun Kwon authored
The BCM2711 has another clock that needs to be ramped up depending on the pixel rate: the pixel BVB clock. Add the code to adjust that clock when changing the mode. [Maxime: Changed the commit log, used clk_set_min_rate] Signed-off-by:
-
Maxime Ripard authored
In order to avoid pixels getting stuck in an unflushable FIFO, we need when we disable the HDMI controller to switch away from getting our pixels from the pixelvalve and instead use blank pixels, and switch back to the pixelvalve when we enable the HDMI controller. Signed-off-by:
-
Maxime Ripard authored
The VID_CTL setup is done in several places in the driver even though it's not really required. Let's simplify it a bit to do the configuration in one go. Signed-off-by:
-
Maxime Ripard authored
In order to prevent some pixels getting stuck in an unflushable FIFO on bcm2711, we need to enable the HVS, the pixelvalve (the CRTC) and the HDMI controller (the encoder) in an intertwined way, and with tight delays. However, the atomic callbacks don't really provide a way to work with either constraints, so we need to roll our own callbacks so that we can provide those guarantees. Since those callbacks have been implemented and called in the CRTC code, we can just implement them in the HDMI driver now. Signed-off-by:
-
Maxime Ripard authored
In order to avoid a pixel getting stuck in an unflushable FIFO, we need to recenter the FIFO every time we're doing a modeset and not only if we're connected to an HDMI monitor. Signed-off-by:
-
Maxime Ripard authored
The current code has some logic, disabled by default, to dump the register setup in the HDMI controller. However, since we're going to split those functions in multiple, shorter, functions that only make sense where they are called in sequence, keeping the register dump makes little sense. Signed-off-by:
-
Maxime Ripard authored
The HDMI driver was registering a single ALSA card so far with the name vc4-hdmi. Obviously, this is not going to work anymore when we will have multiple HDMI controllers since we will end up trying to register two files with the same name. Let's use the variant to avoid that name conflict. Signed-off-by:
-
Dave Stevenson authored
The audio configuration has changed for the BCM2711, with notably a different parent clock and a different channel configuration. Make that modular to be able to support the BCM2711. Signed-off-by:
-
Dave Stevenson authored
ALSA's iec958 plugin by default sets the block start preamble to 8, whilst this driver was programming the hardware to expect 0xF. Amend the hardware config to match ALSA. Signed-off-by:
-
Dave Stevenson authored
If the encoder is disabled and re-enabled (eg mode change) all infoframes are reset, whilst the audio subsystem know nothing about this change. The driver therefore needs to reinstate the audio infoframe for itself. Signed-off-by:
-
Dave Stevenson authored
The register range used for audio setup in the previous generations of SoC were always the second range in the device tree. However, now that the BCM2711 has way more register ranges, it makes sense to retrieve it by names for it, while preserving the id-based lookup as a fallback. Signed-off-by:
-
Maxime Ripard authored
The HSM clock needs to be running at 101% the pixel clock of the HDMI controller, however it's shared between the two HDMI controllers, which means that if the resolutions are different between the two HDMI controllers, and the lowest resolution is on the second (in enable order) controller, the first HDMI controller will end up with a smaller than expected clock rate. Since we don't really need an exact frequency there, we can simply change the minimum rate we expect instead. Signed-off-by:
-
Maxime Ripard authored
The HSM clock needs to be setup at around 101% of the pixel rate. This was done previously by setting the clock rate to 163.7MHz at probe time and only check in mode_valid whether the mode pixel clock was under the pixel clock +1% or not. However, with 4k we need to change that frequency to a higher frequency than 163.7MHz, and yet want to have the lowest clock as possible to have a decent power saving. Let's change that logic a bit by setting the clock rate of the HSM clock to the pixel rate at encoder_enable time. This would work for the BCM2711 that support 4k resolutions and has a clock that can provide it, but we still have to take care of a 4k panel plugged on a BCM283x SoCs that wouldn't be able to use those modes, so let's define the limit in the variant. Signed-off-by:
-
Maxime Ripard authored
The mode_valid hook on the encoder uses a pointer to a drm_encoder called crtc, which is pretty confusing. Let's rename it to encoder to make it clear what it is. Signed-off-by:
-
Maxime Ripard authored
The CEC_CLOCK_DIV define is not used anywhere in the driver, let's remove it. Signed-off-by:
-
Maxime Ripard authored
Similarly to the audio support, CEC support is not there yet for the BCM2711, so let's skip entirely the CEC initialization through a variant flag. Signed-off-by:
-
Maxime Ripard authored
The CEC init code was put directly into the bind function, which was quite inconsistent with how the audio support was done, and would prevent us from further changes to skip that initialisation entirely. Signed-off-by:
-
Maxime Ripard authored
The HDMI driver was registering a single debugfs file so far with the name hdmi_regs. Obviously, this is not going to work anymore when will have multiple HDMI controllers since we will end up trying to register two files with the same name. Let's use the variant to avoid that name conflict. Signed-off-by:
-
Maxime Ripard authored
The vc4 CRTC will use the encoder type to control its output clock muxing. However, this will be different from HDMI0 to HDMI1, so let's store our type in the variant structure so that we can support multiple controllers later on. Signed-off-by:
-
Maxime Ripard authored
Similarly to the previous patches, the timings setup in the HDMI controller of the BCM2711 is slightly different, mostly because it supports higher resolutions and thus needed more spaces for the various timings, resulting in the register layout changing. Let's add a callback for that as well. Signed-off-by:
-
