Vaibhav Gupta [Wed, 19 Aug 2020 18:56:50 +0000 (00:26 +0530)]
fbdev: cyber2000fb: use generic power management
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".
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-9-vaibhavgupta40@gmail.com
Vaibhav Gupta [Wed, 19 Aug 2020 18:56:49 +0000 (00:26 +0530)]
fbdev: savagefb: use generic power management
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. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Now,
- savagefb_suspend() had a "pm_message_t" type parameter as per legacy
PCI PM framework that got deprecated in generic.
- Rename the callback as savagefb_suspend_late() and preserve the
parameter.
- Define 3 new callbacks as:
* savagefb_suspend()
* savagefb_freeze()
* savagefb_hibernate()
which in turn call savagefb_suspend_late() by passing appropriate value
for "pm_message_t" type parameter.
- Bind the callbacks in "struct dev_pm_ops" type variable
"savagefb_pm_ops".
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-8-vaibhavgupta40@gmail.com
Vaibhav Gupta [Wed, 19 Aug 2020 18:56:48 +0000 (00:26 +0530)]
fbdev: nvidia: use generic power management
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. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Now,
- nvidiafb_suspend() had a "pm_message_t" type parameter as per legacy
PCI PM framework that got deprecated in generic.
- Rename the callback as nvidiafb_suspend_late() and preserve the
parameter.
- Define 3 new callbacks as:
* nvidiafb_suspend()
* nvidiafb_freeze()
* nvidiafb_hibernate()
which in turn call nvidiafb_suspend_late() by passing appropriate value
for "pm_message_t" type parameter.
- Bind the callbacks in "struct dev_pm_ops" type variable
"nvidiafb_pm_ops".
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-7-vaibhavgupta40@gmail.com
Vaibhav Gupta [Wed, 19 Aug 2020 18:56:47 +0000 (00:26 +0530)]
fbdev: aty128fb: use generic power management
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. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Now,
- aty128_pci_suspend() had a "pm_message_t" type parameter as per legacy
PCI PM framework that got deprecated in generic.
- Rename the callback as aty128_pci_suspend_late() and preserve the
parameter.
- Define 3 new callbacks as:
* aty128_pci_suspend()
* aty128_pci_freeze()
* aty128_pci_hibernate()
which in turn call aty128_pci_suspend_late() by passing appropriate
value for "pm_message_t" type parameter.
- Bind the callbacks in "struct dev_pm_ops" type variable
"aty128_pci_pm_ops".
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-6-vaibhavgupta40@gmail.com
Vaibhav Gupta [Wed, 19 Aug 2020 18:56:46 +0000 (00:26 +0530)]
fbdev: aty: use generic power management
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. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Now,
- atyfb_pci_suspend() had a "pm_message_t" type parameter as per legacy
PCI PM framework, that got deprecated in generic.
- Rename the callback as atyfb_pci_suspend_late() and preserve the
parameter.
- Define 3 new callbacks as:
* atyfb_pci_suspend()
* atyfb_pci_freeze()
* atyfb_pci_hibernate()
which in turn call atyfb_pci_suspend_late() by passing appropriate
value for "pm_message_t" type parameter.
- Bind the callbacks in "struct dev_pm_ops" type variable
"atyfb_pci_pm_ops".
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-5-vaibhavgupta40@gmail.com
Vaibhav Gupta [Wed, 19 Aug 2020 18:56:45 +0000 (00:26 +0530)]
fbdev: via-core: use generic power management
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 [Wed, 19 Aug 2020 18:56:44 +0000 (00:26 +0530)]
fbdev: lxfb: use generic power management
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 <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-3-vaibhavgupta40@gmail.com
Vaibhav Gupta [Wed, 19 Aug 2020 18:56:43 +0000 (00:26 +0530)]
fbdev: gxfb: use generic power management
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: 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-2-vaibhavgupta40@gmail.com
Tom Rix [Wed, 5 Aug 2020 14:52:08 +0000 (07:52 -0700)]
video: fbdev: sis: fix null ptr dereference
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:
544393fe584d ("[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: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200805145208.17727-1-trix@redhat.com
Colin Ian King [Wed, 5 Aug 2020 10:28:05 +0000 (11:28 +0100)]
omapfb: fix spelling mistake "propert" -> "property"
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: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200805102805.15353-1-colin.king@canonical.com
Rodrigo Alencar [Fri, 24 Jul 2020 20:22:18 +0000 (17:22 -0300)]
video: fbdev: ssd1307fb: Added support to Column offset
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: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1595622138-3965-1-git-send-email-455.rodrigo.alencar@gmail.com
Colin Ian King [Thu, 23 Jul 2020 17:02:27 +0000 (18:02 +0100)]
video: fbdev: vga16fb: fix setting of pixclock because a pass-by-value error
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: Colin Ian King <colin.king@canonical.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
[b.zolnierkie: minor patch summary fixup]
[b.zolnierkie: removed "Fixes:" tag (not in upstream tree)]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200723170227.996229-1-colin.king@canonical.com
Evgeny Novikov [Mon, 13 Jul 2020 08:05:32 +0000 (11:05 +0300)]
fbdev: sm712fb: handle ioremap() errors in probe
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: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200713080532.15504-1-novikov@ispras.ru
George Kennedy [Tue, 7 Jul 2020 19:26:03 +0000 (15:26 -0400)]
fbmem: add margin check to fb_check_caps()
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: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1594149963-13801-1-git-send-email-george.kennedy@oracle.com
Christian König [Mon, 7 Sep 2020 11:44:36 +0000 (13:44 +0200)]
drm/ttm: merge offset and base in ttm_bus_placement
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 [Mon, 7 Sep 2020 08:45:52 +0000 (10:45 +0200)]
drm/qxl: don't touch mem.bus.offset
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: Christian König <christian.koenig@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/389456/
Neil Armstrong [Mon, 7 Sep 2020 10:27:11 +0000 (12:27 +0200)]
drm/bridge: dw-mipi-dsi: fix dw_mipi_dsi_debugfs_show/write warnings
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:
e2435d69204c ("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
Rodrigo Siqueira [Sun, 30 Aug 2020 14:20:00 +0000 (10:20 -0400)]
drm/vkms: Add support for writeback
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 [Sun, 30 Aug 2020 14:19:59 +0000 (10:19 -0400)]
drm/vkms: Compute CRC without change input data
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: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Reviewed-by: Melissa Wen <melissa.srw@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200830142000.146706-3-rodrigosiqueiramelo@gmail.com
Rodrigo Siqueira [Sun, 30 Aug 2020 14:19:58 +0000 (10:19 -0400)]
drm/vkms: Decouple crc operations from composer
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: Melissa Wen <melissa.srw@gmail.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Reviewed-by: Melissa Wen <melissa.srw@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200830142000.146706-2-rodrigosiqueiramelo@gmail.com
Dave Airlie [Mon, 24 Aug 2020 23:46:00 +0000 (09:46 +1000)]
drm/ttm: remove bdev from ttm_tt
I want to split this structure up and use it differently,
step one remove bdev pointer from it and pass it explicitly.
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-4-airlied@gmail.com
Maxime Ripard [Thu, 3 Sep 2020 08:01:51 +0000 (10:01 +0200)]
drm/vc4: drv: Support BCM2711
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 [Thu, 3 Sep 2020 08:01:50 +0000 (10:01 +0200)]
dt-bindings: display: vc4: Document BCM2711 VC5
The BCM2711 comes with a new VideoCore. Add a compatible for 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: 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 [Thu, 3 Sep 2020 08:01:49 +0000 (10:01 +0200)]
dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
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 <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: Rob Herring <robh@kernel.org>
Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ecd686e9b2335275bfb1ccfe1878305367b34bf3.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:48 +0000 (10:01 +0200)]
drm/vc4: hdmi: Support the BCM2711 HDMI controllers
Now that the driver is ready for it, let's bring in the HDMI controllers
variants for 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: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b540c7a9ebb7ad51da39271a8388b69c7e27e582.1599120059.git-series.maxime@cerno.tech
Hoegeun Kwon [Thu, 3 Sep 2020 08:01:47 +0000 (10:01 +0200)]
drm/vc4: hdmi: Add pixel BVB clock control
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: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20200901040759.29992-3-hoegeun.kwon@samsung.com
Link: https://patchwork.freedesktop.org/patch/msgid/d757ddd6549da140f178563e5fd2bf1d129913fd.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:46 +0000 (10:01 +0200)]
drm/vc4: hdmi: Switch to blank pixels when disabled
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 <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/fde3efb1ad79f4476a73d310cbba3ec07dc6dabe.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:45 +0000 (10:01 +0200)]
drm/vc4: hdmi: Do the VID_CTL configuration at once
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 <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/08e7ebb605a560fcc149b69b4af52753a7870b2f.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:44 +0000 (10:01 +0200)]
drm/vc4: hdmi: Implement finer-grained hooks
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 <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/2e9226d971117065f3b97e597f04f7fe2f0c134c.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:43 +0000 (10:01 +0200)]
drm/vc4: hdmi: Always recenter the HDMI FIFO
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 <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/b3faaf05ac6c4d3c364d28fa441571eb85903269.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:42 +0000 (10:01 +0200)]
drm/vc4: hdmi: Remove register dumps in enable
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 <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/c8c8d388f2d32fc3536336be36d003a862487eb7.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:41 +0000 (10:01 +0200)]
drm/vc4: hdmi: Deal with multiple ALSA cards
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: 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/e60a37444e848a384a45707a21d6df8883115f86.1599120059.git-series.maxime@cerno.tech
Dave Stevenson [Thu, 3 Sep 2020 08:01:40 +0000 (10:01 +0200)]
drm/vc4: hdmi: Add audio-related callbacks
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 <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/85a8ca721c2d800be758c55870cea98536749680.1599120059.git-series.maxime@cerno.tech
Dave Stevenson [Thu, 3 Sep 2020 08:01:39 +0000 (10:01 +0200)]
drm/vc4: hdmi: Set the b-frame marker to the match ALSA's default.
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 <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/d0b126deb228baf1244c91e02ac0a8f7c9c60dc5.1599120059.git-series.maxime@cerno.tech
Dave Stevenson [Thu, 3 Sep 2020 08:01:38 +0000 (10:01 +0200)]
drm/vc4: hdmi: Reset audio infoframe on encoder_enable if previously streaming
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 <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/cd579ccc2c9b9d2fce0ebaf32f847cedb0e4a7a2.1599120059.git-series.maxime@cerno.tech
Dave Stevenson [Thu, 3 Sep 2020 08:01:37 +0000 (10:01 +0200)]
drm/vc4: hdmi: Use reg-names to retrieve the HDMI audio registers
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: 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/a1ba5605fe1006a1ead5262ef3d66ea5d0750381.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:36 +0000 (10:01 +0200)]
drm/vc4: hdmi: Use clk_set_min_rate instead
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 <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/821992209cc0d7a83254bf26fe2bf507ef0994d2.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:35 +0000 (10:01 +0200)]
drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate
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 <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/7e692ddc231d33dd671e70ea04dd1dcf56c1ecb3.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:34 +0000 (10:01 +0200)]
drm/vc4: hdmi: Rename drm_encoder pointer in mode_valid
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 <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/7fbabab03992efe4a3a3640ac5ee2bb49b1c7338.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:33 +0000 (10:01 +0200)]
drm/vc4: hdmi: Remove unused CEC_CLOCK_DIV define
The CEC_CLOCK_DIV define is not used anywhere in the driver, let's remove
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/53805cc47e99a137e5f08c92fb781cc2e2134299.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:32 +0000 (10:01 +0200)]
drm/vc4: hdmi: Add CEC support flag
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 <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/bd0c4afa83b4e121692352cdc2dd1886162c7552.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:31 +0000 (10:01 +0200)]
drm/vc4: hdmi: Move CEC init to its own function
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 <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/21f4717e076291522d0784a7fd3774d8e97eaf01.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:30 +0000 (10:01 +0200)]
drm/vc4: hdmi: Deal with multiple debugfs files
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 <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/9505c1eb40b3ef3709277bf9e8af77917b249c32.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:29 +0000 (10:01 +0200)]
drm/vc4: hdmi: Store the encoder type in the variant structure
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 <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/2736a86b498551ba9dbc5803c5bb910627a2550c.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:28 +0000 (10:01 +0200)]
drm/vc4: hdmi: Add a set_timings callback
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: 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/0cfcbb379212f90b4abc76c0ccf3b90d1d7c0268.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:27 +0000 (10:01 +0200)]
drm/vc4: hdmi: Add a CSC setup callback
Similarly to the previous patches, the CSC setup is slightly different in
the BCM2711 than in the previous generations. Let's add a callback for 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/5c19bbf10153cb42ca0fb67e08606c8295c17236.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:26 +0000 (10:01 +0200)]
drm/vc4: hdmi: Add PHY RNG enable / disable function
Let's continue the implementation of hooks for the parts that change in the
BCM2711 SoC with the PHY RNG 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/216155f1c0b83e622ac60a2f7d00eb707de3acba.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:25 +0000 (10:01 +0200)]
drm/vc4: hdmi: Add PHY init and disable function
The HDMI PHY in the BCM2711 HDMI controller is significantly more
complicated to setup than in the older BCM283x SoCs.
Let's add hooks to enable and disable the PHY.
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/7216826284dbc60a58bdacd662805d20699e5c80.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:24 +0000 (10:01 +0200)]
drm/vc4: hdmi: Add reset callback
The BCM2711 and BCM283x HDMI controllers use a slightly different reset
sequence, so let's add a callback to reset the controller.
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/a34bcb493da07eae58ed704f65e72ce0748e8952.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:23 +0000 (10:01 +0200)]
drm/vc4: hdmi: Implement a register layout abstraction
The HDMI controllers found in the BCM2711 have most of the registers
reorganized in multiple registers areas and at different offsets than
previously found.
The logic however remains pretty much the same, so it doesn't really make
sense to create a whole new driver and we should share the code as much as
possible.
Let's implement some indirection to wrap around a register and depending on
the variant will lookup the associated register on that particular variant.
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/3070236daff920e7edd11c5a72ac31fd0f6a656b.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:22 +0000 (10:01 +0200)]
drm/vc4: hdmi: Introduce resource init and variant
The HDMI controllers found in the BCM2711 has a pretty different clock and
registers areas than found in the older BCM283x SoCs.
Let's create a variant structure to store the various adjustments we'll
need later on, and a function to get the resources needed for one
particular version.
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/71cfa3ce3d865bbab52a0e5651bc052dc4893f11.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:21 +0000 (10:01 +0200)]
drm/vc4: hdmi: Remove vc4_hdmi_connector
The vc4_hdmi_connector was only used to switch between drm_connector to
drm_encoder. However, we can now use vc4_hdmi to do the switch, so that
structure is redundant.
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/aee5120728db350b19c074de4290eafaf01e6671.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:20 +0000 (10:01 +0200)]
drm/vc4: hdmi: Remove vc4_dev hdmi pointer
Now that we don't have any users anymore, we can kill that pointer.
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/d7ebf50319bbd902e4b7b7c39ae1612c3b38e6b2.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:19 +0000 (10:01 +0200)]
drm/vc4: hdmi: Retrieve the vc4_hdmi at unbind using our device
The unbind function needs to retrieve a vc4_hdmi structure pointer through
the struct device that we're given since we want to support multiple HDMI
controllers.
However, our optional ASoC support doesn't make that trivial since it will
overwrite the device drvdata if we use it, but obviously won't if we don't
use it.
Let's make sure the fields are at the proper offset to be able to cast
between the snd_soc_card structure and the vc4_hdmi structure
transparently so we can support both cases.
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/717082cba06b5c06280f26c56c08aee512365ed3.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:18 +0000 (10:01 +0200)]
drm/vc4: hdmi: Pass vc4_hdmi to CEC code
Our CEC code also retrieves the associated vc4_hdmi by setting the
vc4_dev pointer as its private data, and then dereferences its vc4_hdmi
pointer.
In order to eventually get rid of that pointer, we can simply pass the
vc4_hdmi pointer directly.
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/cb575cb9e13018bce131b8535e5b572dc1027877.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:17 +0000 (10:01 +0200)]
drm/vc4: hdmi: Add container_of macros for encoders and connectors
Whenever the code needs to access the vc4_hdmi structure from a DRM
connector or encoder, it first accesses the drm_device associated to the
connector, then retrieve the drm_dev private data which gives it a
pointer to our vc4_dev, and will finally follow the vc4_hdmi pointer in
that structure.
That will also give us some trouble when having multiple controllers,
but now that we have our encoder and connector structures that are part
of vc4_hdmi, we can simply call container_of on the DRM connector or
encoder and retrieve the vc4_hdmi structure directly.
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/536ecce5898ea75839fa3788b876009d69a5ccae.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:16 +0000 (10:01 +0200)]
drm/vc4: hdmi: Use local vc4_hdmi directly
The function vc4_hdmi_connector_detect access its vc4_hdmi struct by
dereferencing the pointer in the structure vc4_dev. This will cause some
issues when we will have multiple HDMI controllers, so let's just use the
local variable for now instead of dereferencing that pointer all the time,
and we'll fix the local variable later.
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/ef92c5582d3b2894128b2272a8ada7cbc20be3d9.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:15 +0000 (10:01 +0200)]
drm/vc4: hdmi: Move accessors to vc4_hdmi
The current driver only supports a single HDMI controller, and part of
the issue is that the main vc4_dev structure holds a pointer to its
(only) HDMI controller, and the HDMI registers accessors will use it to
retrieve the mapped addresses.
Let's modify those accessors to use directly the vc4_hdmi structure so
that we can eventually get rid of that single global pointer.
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/886b955586264ce078d7d35e9b8ef9ae51675c27.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:14 +0000 (10:01 +0200)]
drm/vc4: hdmi: Rename hdmi to vc4_hdmi
The driver isn't consistent with the name given to the vc4_hdmi
structure pointer in its functions. Make sure to use a consistent name.
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/696be840dc427245afe94b43e0b829c728d948a7.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:13 +0000 (10:01 +0200)]
drm/vc4: hdmi: Remove DDC argument to connector_init
Now that we are passing the vc4_hdmi structure to the connector init
function, we can simply use the pointer in that structure instead of
having the pointer as an argument.
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/4fe1b45fe45e4ba57d40154da010807d4e5db86c.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:12 +0000 (10:01 +0200)]
drm/vc4: hdmi: rework connectors and encoders
the vc4_hdmi driver has some custom structures to hold the data it needs to
associate with the drm_encoder and drm_connector structures.
However, it allocates them separately from the vc4_hdmi structure which
makes it more complicated than it needs to be.
Move those structures to be contained by vc4_hdmi and update the code
accordingly.
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/93b418d63c876355af2b3d3afebe31a256268623.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:11 +0000 (10:01 +0200)]
drm/vc4: hdmi: Move structure to header
We will need to share the vc4_hdmi and related structures with multiple
files, so let's create a header for 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: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/db3ff2babc914e38e86f794c4e49128697aed887.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:10 +0000 (10:01 +0200)]
drm/vc4: hdmi: Use debugfs private field
We're calling vc4_debugfs_add_file with our struct vc4_hdmi pointer set
in the private field, but we don't use that field and go through the
main struct vc4_dev to get it.
Let's use the private field directly, that will save us some trouble
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/24028dc06c379dbc71f98e027cce2839fdd446ce.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:09 +0000 (10:01 +0200)]
drm/vc4: crtc: Add BCM2711 pixelvalves
The BCM2711 has 5 pixelvalves, so now that our driver is ready, let's add
support for them.
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/2553ec9ece0d8a0e5299ff74ed932a38703c5db9.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:08 +0000 (10:01 +0200)]
dt-bindings: display: vc4: pv: Add BCM2711 pixel valves
The BCM2711 comes with other pixelvalves that have different requirements
and capabilities. Let's document their compatible.
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: Rob Herring <robh+dt@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/3a21824460d96245984d730e446863a4853f2ae5.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:07 +0000 (10:01 +0200)]
drm/vc4: drv: Disable the CRTC at boot time
In order to prevent issues during the firmware to KMS transition, we need
to make sure the pixelvalve are disabled at boot time so that the DRM state
matches the hardware state.
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/ad57f1bdeae7a99631713b0fc193c86f223de042.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:06 +0000 (10:01 +0200)]
drm/vc4: crtc: Move the CRTC disable out
We'll need to reuse the part that disables the HVS and PixelValve during
boot too, so let's create a separate 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/5288fb72ed2da643085dce1bc7f6d6f656bf176e.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:05 +0000 (10:01 +0200)]
drm/vc4: hvs: Introduce a function to get the assigned FIFO
At boot time, if we detect that a pixelvalve has been enabled, we need to
be able to retrieve the HVS channel it has been assigned to so that we can
disable that channel too. Let's create that function that returns the FIFO
or an error from a given output.
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/178192d90874559b8386139f2226e773347729fc.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:04 +0000 (10:01 +0200)]
drm/vc4: hvs: Make the stop_channel function public
During the transition from the firmware to the KMS driver, we need to pay
particular attention to how we deal with the pixelvalves that have already
been enabled, otherwise either timeouts or stuck pixels can occur. We'll
thus need to call the function to stop an HVS channel at boot.
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/a9d5f0891c3bc1deb6b16d56ca6994ed912ec7c7.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:03 +0000 (10:01 +0200)]
drm/vc4: crtc: Clear the PixelValve FIFO during configuration
Even though it's not really clear why we need to flush the PV FIFO during
the configuration even though we started by flushing it, experience shows
that without it we get a stale pixel stuck in the FIFO between the HVS and
the PV.
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/ccd6269ba37b2f849ba6e62471c99bd93a4548a0.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:02 +0000 (10:01 +0200)]
drm/vc4: crtc: Clear the PixelValve FIFO on disable
In order to avoid a stale pixel getting stuck on mode change or a disable
/ enable cycle, we need to make sure to flush the PV FIFO on disable.
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/26fe48b09d77088679ed0c8cb8cf0db2f108195e.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:01 +0000 (10:01 +0200)]
drm/vc4: crtc: Add a delay after disabling the PixelValve output
In order to avoid pixels getting stuck in the (unflushable) FIFO between
the HVS and the PV, we need to add some delay after disabling the PV output
and before disabling the HDMI controller. 20ms seems to be good enough so
let's use 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: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/15cf215bd2ceebd203c4010c09c21a4019c650ed.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:01:00 +0000 (10:01 +0200)]
drm/vc4: encoder: Add finer-grained encoder callbacks
In the BCM2711, the setup of the HVS, pixelvalve and HDMI controller
requires very precise ordering and timing that the regular atomic callbacks
don't provide. Let's add new callbacks on top of the regular ones to be
able to split the configuration as 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: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1dd78efe8f29add73c97d0148cfd4ec8e34aaf22.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:00:59 +0000 (10:00 +0200)]
drm/vc4: crtc: Move HVS channel init before the PV initialisation
In order to avoid stale pixels getting stuck in an intermediate FIFO
between the HVS and the pixelvalve on BCM2711, we need to configure the HVS
channel before the pixelvalve is reset and configured.
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/9d7c5a03bc1a1e6d50f7b617cc2d8a46a4bbb7bc.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:00:58 +0000 (10:00 +0200)]
drm/vc4: crtc: Remove redundant pixelvalve reset
Since we moved the pixelvalve configuration to atomic_enable, we're now
first calling the function that resets the pixelvalve and then the one that
configures it.
However, the first thing the latter is doing is calling the reset function,
meaning that we reset twice our pixelvalve. Let's remove the first call.
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/a0a31af0d4a7a070de979f0e5b618d9e2c730e7f.1599120059.git-series.maxime@cerno.tech
Maxime Ripard [Thu, 3 Sep 2020 08:00:57 +0000 (10:00 +0200)]
drm/vc4: crtc: Remove mode_set_nofb
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:56 +0000 (10:00 +0200)]
drm/vc4: hvs: Make sure our channel is reset
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:55 +0000 (10:00 +0200)]
drm/vc4: crtc: Move the HVS gamma LUT setup to our init function
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:54 +0000 (10:00 +0200)]
drm/vc4: crtc: Move HVS init and close to a function
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:53 +0000 (10:00 +0200)]
drm/vc4: crtc: Move PV dump to config_pv
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:52 +0000 (10:00 +0200)]
drm/vc4: crtc: Turn pixelvalve reset into a function
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:51 +0000 (10:00 +0200)]
drm/vc4: crtc: Disable color management for HVS5
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:50 +0000 (10:00 +0200)]
drm/vc4: crtc: Add HDMI1 encoder type
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:49 +0000 (10:00 +0200)]
drm/vc4: crtc: Rename HDMI encoder type to HDMI0
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:48 +0000 (10:00 +0200)]
drm/vc4: crtc: Add function to compute FIFO level bits
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:47 +0000 (10:00 +0200)]
drm/vc4: crtc: Add FIFO depth to vc4_crtc_data
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:46 +0000 (10:00 +0200)]
drm/vc4: crtc: Assign output to channel automatically
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:45 +0000 (10:00 +0200)]
drm/vc4: kms: Convert to for_each_new_crtc_state
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:44 +0000 (10:00 +0200)]
drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:43 +0000 (10:00 +0200)]
drm/vc4: crtc: Use local chan variable
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:42 +0000 (10:00 +0200)]
drm/vc4: crtc: Rename HVS channel to output
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:41 +0000 (10:00 +0200)]
drm/vc4: crtc: Move the cob allocation outside of bind
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:40 +0000 (10:00 +0200)]
drm/vc4: crtc: Use a shared interrupt
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:39 +0000 (10:00 +0200)]
drm/vc4: crtc: Deal with different number of pixel per clock
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:38 +0000 (10:00 +0200)]
drm/vc4: plane: Create more planes
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
Dave Stevenson [Thu, 3 Sep 2020 08:00:37 +0000 (10:00 +0200)]
drm/vc4: plane: Optimize the LBM allocation size
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
Dave Stevenson [Thu, 3 Sep 2020 08:00:36 +0000 (10:00 +0200)]
drm/vc4: plane: Change LBM alignment constraint on LBM
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:35 +0000 (10:00 +0200)]
drm/vc4: hvs: Boost the core clock during modeset
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
Dave Stevenson [Thu, 3 Sep 2020 08:00:34 +0000 (10:00 +0200)]
drm/vc4: Add support for the BCM2711 HVS5
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
Maxime Ripard [Thu, 3 Sep 2020 08:00:33 +0000 (10:00 +0200)]
dt-bindings: display: Add support for the BCM2711 HVS
The HVS found in the BCM2711 is slightly different from the previous
generations, let's add a compatible for 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: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/a6b4c9ee03bc8f950adc6c493db70cd540c2f902.1599120059.git-series.maxime@cerno.tech
projects / platform / kernel / linux-rpi.git / log