- 20 Sep, 2023 14 commits
-
-
Tomi Valkeinen authored
The DSI horizontal timing calculations done by the driver seem to often lead to underflows or overflows, depending on the videomode. There are two main things the current driver doesn't seem to get right: DSI HSW and HFP, and VSDly. However, even following Toshiba's documentation it seems we don't always get a working display. This patch attempts to fix the horizontal timings for DSI event mode, and on a system with a DSI->HDMI encoder, a lot of standard HDMI modes now seem to work. The work relies on Toshiba's documentation, but also quite a bit on empirical testing. This also adds timing related debug prints to make it easier to improve on this later. The DSI pulse mode has only been tested with a fixed-resolution panel, which limits the testing of different modes on DSI pulse mode. However, as the VSDly calculation also affects pulse mode, so this might cause a regression. Reviewed-by:
Peter Ujfalusi <peter.ujfalusi@gmail.com> Tested-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-12-31725f008a50@ideasonboard.com
-
Tomi Valkeinen authored
The tc358768_ns_to_cnt() is, most likely, supposed to do a div-round-up operation, but it misses subtracting one from the dividend. Fix this by just using DIV_ROUND_UP(). Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Reviewed-by:
-
Tomi Valkeinen authored
The driver defines TC358768_PRECISION as 1000, and uses "nsk" to refer to clock periods. The original author does not remember where all this came from. Effectively the driver is using picoseconds as the unit for clock periods, yet referring to them by "nsk". Clean this up by just saying the periods are in picoseconds. Reviewed-by:
-
Tomi Valkeinen authored
The Toshiba documentation talks about HSByteClk when referring to the DSI HS byte clock, whereas the driver uses 'dsibclk' name. Also, in a few places the driver calculates the byte clock from the DSI clock, even if the byte clock is already available in a variable. To align the driver with the documentation, change the 'dsibclk' variable to 'hsbyteclk'. This also make it easier to visually separate 'dsibclk' and 'dsiclk' variables. Reviewed-by:
-
Tomi Valkeinen authored
Simplify the code by capturing the priv->dev value to dev variable, and use it. Reviewed-by:
-
Tomi Valkeinen authored
The driver debug prints DSI related timings as raw register values in hex. It is much more useful to see the "logical" value of the timing, not the register value. Change the prints to print the values separately, in case a single register contains multiple values, and use %u to have it in a more human consumable form. Reviewed-by:
-
Tomi Valkeinen authored
The TC358768 documentation uses HFP, HBP, etc. values to deal with the video mode, while the driver currently uses the DRM display mode (htotal, hsync_start, etc). Change the driver to convert the DRM display mode to struct videomode, which then allows us to use the same units the documentation uses. This makes it much easier to work on the code when using the TC358768 documentation as a reference. Reviewed-by:
-
Tomi Valkeinen authored
As is quite common, some of TC358768's PLL register fields are to be programmed with (value - 1). Specifically, the FBD and PRD, multiplier and divider, are such fields. However, what the driver currently does is that it considers that the formula used for PLL rate calculation is: RefClk * [(FBD + 1)/ (PRD + 1)] * [1 / (2^FRS)] where FBD and PRD are values directly from the registers, while a more sensible way to look at it is: RefClk * FBD / PRD * (1 / (2^FRS)) and when the FBD and PRD values are written to the registers, they will be subtracted by one. Change the driver accordingly, as it simplifies the PLL code. Reviewed-by:
-
Tomi Valkeinen authored
The driver has a few places where it does: if (thing_is_enabled_in_config) update_thing_bit_in_hw() This means that if the thing is _not_ enabled, the bit never gets cleared. This affects the h/vsyncs and continuous DSI clock bits. Fix the driver to always update the bit. Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Reviewed-by:
-
Tomi Valkeinen authored
As the TC358768 is a DPI to DSI bridge, the DSI side does not need to define h/v sync polarities. This means that sometimes we have a mode without defined sync polarities, which does not work on the DPI side. Add a mode_fixup hook to default to positive sync polarities. Reviewed-by:
-
Tomi Valkeinen authored
smatch reports: drivers/gpu/drm/bridge/tc358768.c:223 tc358768_update_bits() error: uninitialized symbol 'orig'. Fix this by bailing out from tc358768_update_bits() if the tc358768_read() produces an error. Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Reviewed-by:
-
Thierry Reding authored
The polarities of the V- and H-sync signals are encoded as flags in the display mode, so use the existing information to setup the signals for the RGB interface. Signed-off-by:
Thierry Reding <treding@nvidia.com> Cc: Thierry Reding <thierry.reding@gmail.com> [tomi.valkeinen@ideasonboard.com: default to positive sync] Reviewed-by:
-
Alicja Michalska authored
Analogix ANX78XX driver is missing definitions for anx7816. It uses the same I2C register set as anx7818. Signed-off-by:
Alicja Michalska <ahplka19@gmail.com> Reviewed-by:
-
Alicja Michalska authored
As requested by Robert Foss <rfoss@kernel.org>, this patch adds definition for anx7816. It supplements the patch submitted to dri-devel. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 19 Sep, 2023 26 commits
-
-
Ben Skeggs authored
- nvkm should provide all this info now - preparation for GSP-RM Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Acked-by:
Danilo Krummrich <me@dakr.org> Signed-off-by:
-
Ben Skeggs authored
- preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
- preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
- removes use of VBIOS data for naming - preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
- output info will be used later to determine MST support Signed-off-by:
-
Ben Skeggs authored
No need to go poking HW directly, and probably shouldn't on GSP-RM. Signed-off-by:
-
Ben Skeggs authored
We've never supported it. Signed-off-by:
-
Ben Skeggs authored
- pre-nv5x doesn't use any of this - preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
- pre-nv5x doesn't use any of this, has its own version DRM-side - preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
- preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
This is presently unused on HW, we read a bunch of regs and calculate the watermark during the second supervisor interrupt. I don't want to change this yet as I need to re-remember how older HW works exactly, but RM wants this info via RPC. Signed-off-by:
-
Ben Skeggs authored
- preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
- passes DPCD information from DRM to NVKM - removes NVKM's own sink caps handling - link still trained from supervisor, more patches to come Signed-off-by:
-
Ben Skeggs authored
- fixes bug preventing this on SST - implement for MST Signed-off-by:
-
Ben Skeggs authored
- fixes some issues tearing down modes on tiled displays Signed-off-by:
-
Ben Skeggs authored
Link training can finally be moved out of the supervisor sequence, but first we need to split DP modesets into separate disable and enable sequences to be able to perform link training between them instead. - preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
- moves building of link rates table from NVKM to DRM - preparing to move link training out of supervisor Signed-off-by:
-
Ben Skeggs authored
- preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
- preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
This just adds a hook for RM to use, HW paths remain untouched, but should probably be cleaned up to use this too at some point. Signed-off-by:
-
Ben Skeggs authored
- was previously part of acquire() Signed-off-by:
-
Ben Skeggs authored
- preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
- these shouldn't be necessary now, and are done in acquire()/release() - preparation for GSP-RM, where we don't control the supervisor Signed-off-by:
-
Ben Skeggs authored
Prior to this commit, KMS would call release() prior to modeset, and the second supervisor interrupt would update SOR routing if needed. Now, KMS will call release() post-modeset and update routing immediately. - preparation for GSP-RM Signed-off-by:
-
Ben Skeggs authored
- release() is being moved post-modeset, preserve hdmi behaviour for now Signed-off-by:
-
Ben Skeggs authored
- was previously part of acquire() - preparation for GSP-RM Signed-off-by:
-
