[PATCH v3 0/3] rockchip-dsi for rk3568
Chris Morgan
macromorgan at hotmail.com
Thu Sep 15 07:47:34 PDT 2022
On Thu, Sep 15, 2022 at 09:16:47AM +0200, Michael Riesch wrote:
> Hi Chris,
>
> On 9/14/22 14:50, Chris Morgan wrote:
> > On Wed, Sep 14, 2022 at 07:46:41AM +0200, Michael Riesch wrote:
> >> Hi Chris,
> >>
> >> On 9/12/22 22:56, Chris Morgan wrote:
> >>> From: Chris Morgan <macromorgan at hotmail.com>
> >>>
> >>> This series adds support for the dsi and dphy controllers on the
> >>> Rockchip RK3568.
> >>>
> >>> Tested on an Anbernic RG503, Anbernic RG353P, and Odroid Go Advance.
> >>>
> >>> Changes since V2:
> >>> - Removed dsi controller patches, as those have been merged upstream.
> >>> - Removed notes about rolling back clock drivers. If I set the parent
> >>> clock of the VOP port I'm using to VPLL and set the clock rate of
> >>> PLL_VPLL to 500MHz this series works correctly for my panels without
> >>> rolling anything back (per Heiko this is the correct way).
> >>
> >> I tried this but it didn't help (neither did reverting ff3187eabb5c
> >> "clk: rockchip: drop CLK_SET_RATE_PARENT from dclk_vop* on rk3568"). On
> >> my display the content is shifted horizontally and the colors are often
> >> wrong.
> >
> > There's still something wrong with the VOP2 driver, and I'm trying to
> > get to the bottom of it. Are you by chance enabling HDMI? Can you check
> > the clock for the dclk_vopx (where x is the port) that you are using?
> > It should be very close or the same as the pixel clock of your panel.
>
> Yes, HDMI is enabled (on VP0) and works fine. MIPI DSI is enabled on
> VP1. The clocks dclk_vopx are:
>
> pll_hpll 1 1 0 148500000
> 0 0 50000 Y
> hpll 3 3 0 148500000
> 0 0 50000 Y
> dclk_vop2 1 1 0 37125000
> 0 0 50000 Y
> dclk_vop0 2 2 0 148500000
> 0 0 50000 Y
> clk_hdmi_ref 1 1 0 148500000
> 0 0 50000 Y
> hpll_ph0 0 0 0 74250000
> 0 0 50000 Y
>
> pll_vpll 1 1 0 500000000
> 0 0 50000 Y
> vpll 1 1 0 500000000
> 0 0 50000 Y
> dclk_vop1 2 2 0 125000000
> 0 0 50000 Y
>
> The pixel clock of my panel is 132 MHz (1080x1920 at 60). Could this
> discrepancy be the cause?
It's too low which likely could be the cause, (honestly not sure) but
otherwise everything looks correct. Maybe try setting the PLL_VPLL
rate to 135000000 to force the panel to go faster (135MHz instead of
125MHz)?
I know for one of my examples the panel's pixel clock is 33500000
and I'm running it at 33333333 and it seems to be okay. The other I
am testing with runs either at 25000000 or 50000000 which evenly
divides with the 500000000, which is why I use it.
You can also experiment with different rates, any rate defined in
rk3568_pll_rates[] should work (though the datasheet says for VOP1
don't run the parent clock over 500000000, and then in the BSP kernel
I see the parent clock in my example it running at 503000000 so who
knows). If need be you can also define a new rate and add it there,
but you'll have to consult the datasheet for which rates are supported
and at which dividers (and also the VPLL and NPLLs don't support frac
rate setting).
Thank you.
>
> > I noticed on mine that the HDMI was interfering with it. For now not
> > only have I disabled the HDMI but also put it on VP0 while my DSI is
> > on VP1 (note that if both are active you'll get a null pointer
> > dereference from the vop2 driver which is another thing I'm chasing
> > down). I think this is because the hdmi_ref is allowed to set its
> > parent clock (which is the PLL_HPLL), so it does to 24000000.
> >
> > Basically here's what I've done to overcome the VOP2 issues and get
> > DSI working with this patch series.
> > 1) Disabled HDMI (with it on VP0).
> > 2) Enabled DSI and the DSI-DPHY (with it on VP1).
> > 3) Set the parent clock of DCLK_VOP0 to PLL_HPLL.
> > 4) Set the parent clock of DCLK_VOP1 to PLL_VPLL.
> > 5) Set the clock rate for PLL_VPLL to 500000000.
>
> I tried to reproduce this. When I disabled HDMI I realized that the
> regulators that produce the 0v9/1v8 image voltages are not turned on.
> They are required for the MIPI DSI TX block, though. Could you take this
> requirement into account and model it in the device tree?
>
> After setting the voltages to always-on as a hack the result was pretty
> much the same: the clock tree is the same as in the case with HDMI and
> also matches your description.
>
> > Doing this allows the DCLK_VOP1 to run at the correct speed for my
> > panel instead of 24000000 like it would otherwise. When this occurs
> > I get a correct image. If for whatever reason the DCLK_VOPx of the
> > port I'm trying to run the panel on is at 24000000 is when I get
> > the shifted image.
> >
> > The long term fix I'm trying to work on is to figure out how to
> > successfully get the VOP2 driver to not crash when VP0 and VP1
> > are both used for the RK3566 (note this actually should work for
> > you on an RK3568 board though), so that whole bit about disabling
> > HDMI might not apply to you if it's enabled.
> >
> > In summary, check the DCLK_VOPx where x is the port you are using.
> > If it's not at or very close to your pixel clock that's probably
> > why your image is shifted, at least it was for me.
>
> OK... I am starting to think that I experience a different bug here.
> I'll clean up my patches and will try again.
>
> Thanks and regards,
> Michael
>
> >
> > Thank you.
> >
> >>
> >>> - Added additional details about refactoring DPHY driver to add
> >>> 2.5GHz for rk356x. All other devices still have a max speed of 1GHz.
> >>> - Notified Heiko that the BIT(5) for both PLL_POST_DIV_ENABLE and
> >>> PLL_POST_DIV_ENABLE_MASK is deliberate, because of how the
> >>> phy_update_bits() works.
> >>>
> >>> Changes since RFCv1:
> >>> - Identified cause of image shift (clock changes).
> >>> - Noted that driver works now.
> >>> - Added devicetree nodes for rk356x.dtsi.
> >>>
> >>> Chris Morgan (3):
> >>> dt-bindings: phy-rockchip-inno-dsidphy: add compatible for rk3568
> >>> phy/rockchip: inno-dsidphy: Add support for rk3568
> >>> arm64: dts: rockchip: Add DSI and DSI-DPHY nodes to rk356x
> >>
> >> I am testing this on a RK3568 EVB1, which has a display mounted on the
> >> PCB. I'll submit the patches that add support for this setup soon. For
> >> the time being a preliminary
> >>
> >> Tested-by: Michael Riesch <michael.riesch at wolfvision.net>
> >>
> >> Thanks for your work!
> >> Best regards,
> >> Michael
> >>
> >>>
> >>> .../bindings/phy/rockchip,px30-dsi-dphy.yaml | 1 +
> >>> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 72 +++++++
> >>> .../phy/rockchip/phy-rockchip-inno-dsidphy.c | 204 ++++++++++++++----
> >>> 3 files changed, 231 insertions(+), 46 deletions(-)
> >>>
More information about the Linux-rockchip
mailing list