Correct computation of TCLK_ZEROCNT register.
This register must be set to a value that ensure that
(TCLK-PREPARECNT + TCLK-ZERO) > 300ns
with the actual value of (TCLK-PREPARECNT + TCLK-ZERO) being
(1 to 2) + (TCLK_ZEROCNT + 1)) x HSByteClkCycle + (PHY output delay)
with PHY output delay being about
(2 to 3) x MIPIBitClk cycle in the BitClk conversion.
Fixes: ff1ca6397b ("drm/bridge: Add tc358768 driver")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-5-francesco@dolcini.it
Always enable HS video mode setting the TXMD bit, without this change no
video output is present with DSI sinks that are setting
MIPI_DSI_MODE_LPM flag (tested with LT8912B DSI-HDMI bridge).
Previously the driver was enabling HS mode only when the DSI sink was
not explicitly setting the MIPI_DSI_MODE_LPM, however this is not
correct.
The MIPI_DSI_MODE_LPM is supposed to indicate that the sink is willing
to receive data in low power mode, however clearing the
TC358768_DSI_CONTROL_TXMD bit will make the TC358768 send video in
LP mode that is not the intended behavior.
Fixes: ff1ca6397b ("drm/bridge: Add tc358768 driver")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-2-francesco@dolcini.it
If we disable vblank when entering self-refresh, vblank APIs (like
DRM_IOCTL_WAIT_VBLANK) no longer work. But user space is not aware when
we enter self-refresh, so this appears to be an API violation -- that
DRM_IOCTL_WAIT_VBLANK fails with EINVAL whenever the display is idle and
enters self-refresh.
The downstream driver used by many of these systems never used to
disable vblank for PSR, and in fact, even upstream, we didn't do that
until radically redesigning the state machine in commit 6c836d965b
("drm/rockchip: Use the helpers for PSR").
Thus, it seems like a reasonable API fix to simply restore that
behavior, and leave vblank enabled.
Note that this appears to potentially unbalance the
drm_crtc_vblank_{off,on}() calls in some cases, but:
(a) drm_crtc_vblank_on() documents this as OK and
(b) if I do the naive balancing, I find state machine issues such that
we're not in sync properly; so it's easier to take advantage of (a).
This issue was exposed by IGT's kms_vblank tests, and reported by
KernelCI. The bug has been around a while (longer than KernelCI
noticed), but was only exposed once self-refresh was bugfixed more
recently, and so KernelCI could properly test it. Some other notes in:
https://lore.kernel.org/dri-devel/Y6OCg9BPnJvimQLT@google.com/
Re: renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin
== Backporting notes: ==
Marking as 'Fixes' commit 6c836d965b ("drm/rockchip: Use the helpers
for PSR"), but it probably depends on commit bed030a49f
("drm/rockchip: Don't fully disable vop on self refresh") as well.
We also need the previous patch ("drm/atomic: Allow vblank-enabled +
self-refresh "disable""), of course.
v3:
* no update
v2:
* skip unnecessary lock/unlock
Fixes: 6c836d965b ("drm/rockchip: Use the helpers for PSR")
Cc: <stable@vger.kernel.org>
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Link: https://lore.kernel.org/dri-devel/Y5itf0+yNIQa6fU4@sirena.org.uk/
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230109171809.v3.2.Ic07cba4ab9a7bd3618a9e4258b8f92ea7d10ae5a@changeid
The self-refresh helper framework overloads "disable" to sometimes mean
"go into self-refresh mode," and this mode activates automatically
(e.g., after some period of unchanging display output). In such cases,
the display pipe is still considered "on", and user-space is not aware
that we went into self-refresh mode. Thus, users may expect that
vblank-related features (such as DRM_IOCTL_WAIT_VBLANK) still work
properly.
However, we trigger the WARN_ONCE() here if a CRTC driver tries to leave
vblank enabled.
Add a different expectation: that CRTCs *should* leave vblank enabled
when going into self-refresh.
This patch is preparation for another patch -- "drm/rockchip: vop: Leave
vblank enabled in self-refresh" -- which resolves conflicts between the
above self-refresh behavior and the API tests in IGT's kms_vblank test
module.
== Some alternatives discussed: ==
It's likely that on many display controllers, vblank interrupts will
turn off when the CRTC is disabled, and so in some cases, self-refresh
may not support vblank. To support such cases, we might consider
additions to the generic helpers such that we fire vblank events based
on a timer.
However, there is currently only one driver using the common
self-refresh helpers (i.e., rockchip), and at least as of commit
bed030a49f ("drm/rockchip: Don't fully disable vop on self refresh"),
the CRTC hardware is powered enough to continue to generate vblank
interrupts.
So we chose the simpler option of leaving vblank interrupts enabled. We
can reevaluate this decision and perhaps augment the helpers if/when we
gain a second driver that has different requirements.
v3:
* include discussion summary
v2:
* add 'ret != 0' warning case for self-refresh
* describe failing test case and relation to drm/rockchip patch better
Cc: <stable@vger.kernel.org> # dependency for "drm/rockchip: vop: Leave
# vblank enabled in self-refresh"
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230109171809.v3.1.I3904f697863649eb1be540ecca147a66e42bfad7@changeid
Create a symlink pointing to USB Type-C connector for DRM connectors
when they are created. The link will be created only if the firmware is
able to describe the connection beween the two connectors.
Currently, even if a display uses a USB Type-C port, there is no way for
the userspace to find which port is used for which display. With the
symlink, display information would be accessible from Type-C connectors
and port information would be accessible from DRM connectors.
Associating the two subsystems, userspace would have potential to expose
and utilize more complex information. ChromeOS intend to use this
information for metrics collection. For example, we want to tell which
port is deriving which displays. Also, combined with USB PD information,
we can tell whether user is charging their device through display.
Chromium patch for parsing the symlink from the kernel is at
http://crrev.com/c/4317207.
We already have a framework in typec port-mapper.c where it goes through
component devices and runs the bind functions for those with matching
_PLD (physical location of device).
https://elixir.bootlin.com/linux/v5.18.1/source/drivers/usb/typec/
port-mapper.c
Since _PLD is ACPI specific field, this linking would only work on ACPI
x86 as long as _PLD field for Type-C connectors and DRM connectors are
correctly added to the firmware.
Currently, USB ports and USB4 ports are added as components to create a
symlink with Type C connector.
USB:
https://lore.kernel.org/all/20211223082349.45616-1-heikki.krogerus
@linux.intel.com/
USB4:
https://lore.kernel.org/all/20220418175932.1809770-3-wonchung@google.com/
So, we follow the same pattern in this patch.
Signed-off-by: Won Chung <wonchung@google.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Manasi Navare <navaremanasi@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230427165813.2844530-1-wonchung@google.com
Expose DRM connector id in device sysfs so that we can map the connector
id to the connector syspath. Currently, even if we can derive the
connector id from modeset, we do not have a way to find the
corresponding connector's syspath.
This is helpful when determining the root connector of MST tree. When a
tree of multiple MST hub is connected to the system, modeset describes
the tree in the PATH blob. For example, consider the following scenario.
+-------------+
| Source | +-------------+
| (Device) | | BranchX |
| | | (MST) |
| [conn6]--->| [port1]--->DisplayA
+-------------+ | |
| | +-------------+
| | | BranchY |
| | | (MST) |
| [port2]--->| [port1]----->DisplayB
+-------------+ | |
| [port2]----->DisplayC
+-------------+
DPMST connector of DisplayA would have "mst:6-1" PATH.
DPMST connector of DisplayB would have "mst:6-2-1" PATH.
DPMST connector of DisplayC would have "mst:6-2-2" PATH.
Given that connector id of 6 is the root of the MST connector tree, we
can utilize this patch to parse through DRM connectors sysfs and find
which connector syspath corresponds to the root connector (id == 6).
ChromeOS intend to use this information for metrics collection. For
example, we want to tell which port is deriving which displays even with
a MST hub. Chromium patch for parsing DRM connector id from the kernel
is at http://crrev.com/c/4317207.
Signed-off-by: Won Chung <wonchung@google.com>
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Manasi Navare <navaremanasi@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329014455.1990104-1-wonchung@google.com
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “receive_timing_debugfs_show”.
Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “vid” behind the null pointer check.
This issue was detected by using the Coccinelle software.
Fixes: b5c84a9edc ("drm/bridge: add it6505 driver")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Link: https://patchwork.freedesktop.org/patch/msgid/fa69384f-1485-142b-c4ee-3df54ac68a89@web.de
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Let’s establish a merge plan for Xe, by writing down clear pre-merge goals, in
order to avoid unnecessary delays.
This initial document starts with a TODO list containing items with clear and
measurable key results. Xe’s initial pull request should only be sent to
dri-devel after all the items are clearly resolved.
Since many of them involve some level of a community consensus, in many cases,
the consensus will be reached in follow-up patches to this document with more
details of the API or helpers that will be developed or modified.
Besides of the items that are highlighted in this document, it is important
to highlight that Oded, has been volunteered to give the overall ack on Xe
driver as the way to confirm that it looks good for upstream.
v2: Incorporated Daniel's feedback:
- Do not make long-running compute a blocker.
- Add a mention to drm-exec that that ties to vm_bind and long-running
compute jobs. Then I also added GPUVA since I recently noticed that this
ties also to the work Matt is doing on that front.
- Added the devcoredump section.
- Add the mention to Oded being volunteered for the overall ack.
v3: Reword a bit the Async VM_BIND to incorporate Daniel's feedback on ensuring
the async vmbind consensus explicitly include Mesa, besides other kernel
drivers.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Francois Dugast <francois.dugast@intel.com>
Signed-off-by: Luis Strano <luis.strano@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230419191913.158807-1-rodrigo.vivi@intel.com
Move the implementation of fb_pgprotect() to fbdev.c and include
<asm/fb.h>. Fixes the following warning:
../arch/x86/video/fbdev.c:14:5: warning: no previous prototype for 'fb_is_primary_device' [-Wmissing-prototypes]
14 | int fb_is_primary_device(struct fb_info *info)
| ^~~~~~~~~~~~~~~~~~~~
Just including <asm/fb.h> results in a number of built-in errors
about undefined function. Moving fb_pgprotect() to the source file
avoids the required include statements in the header. The function
is only called occasionally from fb_mmap(), [1] so having it as static
inline had no benefit.
While at it, fix the codying style in fbdev.c.
Link: https://elixir.bootlin.com/linux/v6.3-rc7/source/drivers/video/fbdev/core/fbmem.c#L1404 # 1
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230424084751.14641-1-tzimmermann@suse.de
The CSC matrices were stored as separate matrix for each colorspace, and
if we wanted a limited or full RGB output.
This created some gaps in our support and we would not always pick the
relevant matrix.
Let's rework our data structure to store one per colorspace, and then a
matrix for limited range and one for full range. This makes us add a new
matrix to support full range BT709 YUV output.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-6-bdd54f66884e@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
YUV444 and YUV422 actually require the same matrix, but programmed
differently.
We've dealt with it in the past by having two matrices, with the one
for YUV444 reordered to accomodate the hardware.
This gets in the way of subsequent reworks so let's define a function
that will take the coefficients swap into account, and remove the now
redundant YUV444 matrix.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-5-bdd54f66884e@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
On VC4, the TV margins on the HDMI connector are implemented by scaling
the planes.
However, if only the TV margins or the connector are changed by a new
state, the planes ending up on that connector won't be. Thus, they won't
be updated properly and we'll effectively ignore that change until the
next commit affecting these planes.
Let's make sure to add all the planes attached to the connector so that
we can update them properly.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-2-bdd54f66884e@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
