| Message ID | 20241203164934.1500616-1-heiko@sntech.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | MIPI DSI phy for rk3588 | expand |
Hi Heiko, On 12/3/24 5:49 PM, Heiko Stuebner wrote: > This adds the phy driver need for DSI output on rk3588. > > The phy itself is used for both DSI output and CSI input, though the > CSI part for the whole chain needs a lot more work, so is left out for > now and only the DSI part implemented. > > This allows the rk3588 with its current VOP support to drive a DSI display > using the DSI2 controller driver I'll submit in a next step. > > Only generic phy interfaces are used, so the DSI part is pretty straight > forward. > Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3588 Tiger with Haikou Video Demo I assume this is the same setup you tested this series with, but confirmation doesn't hurt. Tested with https://lore.kernel.org/linux-rockchip/20241127143719.660658-4-heiko@sntech.de/ applied on top. Thanks! Quentin
Hi phy-maintainers, Am Dienstag, 3. Dezember 2024, 17:49:30 MEZ schrieb Heiko Stuebner: > This adds the phy driver need for DSI output on rk3588. > > The phy itself is used for both DSI output and CSI input, though the > CSI part for the whole chain needs a lot more work, so is left out for > now and only the DSI part implemented. > > This allows the rk3588 with its current VOP support to drive a DSI display > using the DSI2 controller driver I'll submit in a next step. > > Only generic phy interfaces are used, so the DSI part is pretty straight > forward. a tiny little ping :-) Is this still in a queue, or did it fall through the cracks during xmas? Thanks a lot Heiko
This adds the phy driver need for DSI output on rk3588. The phy itself is used for both DSI output and CSI input, though the CSI part for the whole chain needs a lot more work, so is left out for now and only the DSI part implemented. This allows the rk3588 with its current VOP support to drive a DSI display using the DSI2 controller driver I'll submit in a next step. Only generic phy interfaces are used, so the DSI part is pretty straight forward. changes in v5: - add bitfield.h for the FIELD_PROP definition (reported by kernel-test-robot) - add Sebastian's Reviewed-by - add Conor's Ack to the dt-binding changes in v4: - moved to #phy-cells = 1 as suggested by Sebastian, with the argument denoting the requested phy-type (C-PHY, D-PHY). This works similarly how the Mediatek C/D-PHY already implements this, see mails around: https://lore.kernel.org/all/20230608200552.GA3303349-robh@kernel.org/ - dropped Krzysztof's review tag from the binding because of this - dropped custom UPDATE macro and use FIELD_PREP instead - build a FIELD_PREP_HIWORD macro for the GRF settings - add received Tested-by tags changes in v3: - add Krzysztof review tag to the binding - address Sebastian's review comments - better error handling - dropping empty function - headers - not using of_match_ptr - this should also make the test-robot happier changes in v2: - fix error in dt-binding example - drop unused frequency table - pull in some more recent improvements from the vendor-kernel which includes a lot less magic values - already include the support for rk3576 - use dev_err_probe Heiko Stuebner (2): dt-bindings: phy: Add Rockchip MIPI C-/D-PHY schema phy: rockchip: Add Samsung MIPI D-/C-PHY driver .../phy/rockchip,rk3588-mipi-dcphy.yaml | 87 + drivers/phy/rockchip/Kconfig | 12 + drivers/phy/rockchip/Makefile | 1 + .../phy/rockchip/phy-rockchip-samsung-dcphy.c | 1604 +++++++++++++++++ 4 files changed, 1704 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/rockchip,rk3588-mipi-dcphy.yaml create mode 100644 drivers/phy/rockchip/phy-rockchip-samsung-dcphy.c