diff options
| author | Heiko Stuebner <[email protected]> | 2019-12-09 15:31:25 +0100 |
|---|---|---|
| committer | Heiko Stuebner <[email protected]> | 2019-12-16 12:01:58 +0100 |
| commit | 25ed8aeb9c396475f48c13abdaf76a2e6e6b117b (patch) | |
| tree | 3b07ba676283a90be8de4b141f1188f7f855dd4f /tools/perf/scripts/python/syscall-counts.py | |
| parent | 2156873f08c7893811f34177aa923ab1ea486591 (diff) | |
drm/bridge/synopsys: dsi: driver-specific configuration of phy timings
The timing values for dw-dsi are often dependent on the used display and
according to Philippe Cornu will most likely also depend on the used phy
technology in the soc-specific implementation.
To solve this and allow specific implementations to define them as needed
add a new get_timing callback to phy_ops and call this from the dphy_timing
function to retrieve the necessary values for the specific mode.
Right now this handles the hs2lp + lp2hs where Rockchip SoCs need handling
according to the phy speed, while STM seems to be ok with static values.
changes in v5:
- rebase on 5.5-rc1
- merge into px30 dsi series to prevent ordering conflicts
changes in v4:
- rebase to make it directly fit on top of drm-misc-next after all
changes in v3:
- check existence of phy_ops->get_timing in __dw_mipi_dsi_probe()
- emit actual error when get_timing() call fails
- add tags from Philippe and Yannick
changes in v2:
- add driver-specific handling, don't force all bridge users to use
the same timings, as suggested by Philippe
Suggested-by: Philippe Cornu <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
Reviewed-by: Philippe Cornu <[email protected]>
Tested-by: Yannick Fertre <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Diffstat (limited to 'tools/perf/scripts/python/syscall-counts.py')
0 files changed, 0 insertions, 0 deletions