All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Morgan <macromorgan@hotmail.com>
To: Michael Riesch <michael.riesch@wolfvision.net>
Cc: Chris Morgan <macroalpha82@gmail.com>,
	linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
	linux-phy@lists.infradead.org, cl@rock-chips.com,
	s.hauer@pengutronix.de, frattaroli.nicolas@gmail.com,
	pgwipeout@gmail.com, heiko@sntech.de,
	krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org,
	vkoul@kernel.org, kishon@ti.com
Subject: Re: [PATCH v3 0/3] rockchip-dsi for rk3568
Date: Wed, 14 Sep 2022 07:50:08 -0500	[thread overview]
Message-ID: <SN6PR06MB5342040C7772D95351DFD22FA5469@SN6PR06MB5342.namprd06.prod.outlook.com> (raw)
In-Reply-To: <1d98ce70-81d5-df92-c881-1d9611042401@wolfvision.net>

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@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.

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.

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.

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@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(-)
> > 

WARNING: multiple messages have this Message-ID (diff)
From: Chris Morgan <macromorgan@hotmail.com>
To: Michael Riesch <michael.riesch@wolfvision.net>
Cc: Chris Morgan <macroalpha82@gmail.com>,
	linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
	linux-phy@lists.infradead.org, cl@rock-chips.com,
	s.hauer@pengutronix.de, frattaroli.nicolas@gmail.com,
	pgwipeout@gmail.com, heiko@sntech.de,
	krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org,
	vkoul@kernel.org, kishon@ti.com
Subject: Re: [PATCH v3 0/3] rockchip-dsi for rk3568
Date: Wed, 14 Sep 2022 07:50:08 -0500	[thread overview]
Message-ID: <SN6PR06MB5342040C7772D95351DFD22FA5469@SN6PR06MB5342.namprd06.prod.outlook.com> (raw)
In-Reply-To: <1d98ce70-81d5-df92-c881-1d9611042401@wolfvision.net>

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@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.

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.

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.

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@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(-)
> > 

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

WARNING: multiple messages have this Message-ID (diff)
From: Chris Morgan <macromorgan@hotmail.com>
To: Michael Riesch <michael.riesch@wolfvision.net>
Cc: Chris Morgan <macroalpha82@gmail.com>,
	linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
	linux-phy@lists.infradead.org, cl@rock-chips.com,
	s.hauer@pengutronix.de, frattaroli.nicolas@gmail.com,
	pgwipeout@gmail.com, heiko@sntech.de,
	krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org,
	vkoul@kernel.org, kishon@ti.com
Subject: Re: [PATCH v3 0/3] rockchip-dsi for rk3568
Date: Wed, 14 Sep 2022 07:50:08 -0500	[thread overview]
Message-ID: <SN6PR06MB5342040C7772D95351DFD22FA5469@SN6PR06MB5342.namprd06.prod.outlook.com> (raw)
In-Reply-To: <1d98ce70-81d5-df92-c881-1d9611042401@wolfvision.net>

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@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.

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.

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.

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@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(-)
> > 

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2022-09-14 12:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-12 20:56 [PATCH v3 0/3] rockchip-dsi for rk3568 Chris Morgan
2022-09-12 20:56 ` Chris Morgan
2022-09-12 20:56 ` Chris Morgan
2022-09-12 20:56 ` [PATCH V3 1/3] dt-bindings: phy-rockchip-inno-dsidphy: add compatible " Chris Morgan
2022-09-12 20:56   ` Chris Morgan
2022-09-12 20:56   ` Chris Morgan
2022-09-12 20:56 ` [PATCH V3 2/3] phy/rockchip: inno-dsidphy: Add support " Chris Morgan
2022-09-12 20:56   ` Chris Morgan
2022-09-12 20:56   ` Chris Morgan
2022-09-12 20:56 ` [PATCH V3 3/3] arm64: dts: rockchip: Add DSI and DSI-DPHY nodes to rk356x Chris Morgan
2022-09-12 20:56   ` Chris Morgan
2022-09-12 20:56   ` Chris Morgan
2022-09-14  4:50   ` Michael Riesch
2022-09-14  4:50     ` Michael Riesch
2022-09-14  4:50     ` Michael Riesch
2022-09-14  5:46 ` [PATCH v3 0/3] rockchip-dsi for rk3568 Michael Riesch
2022-09-14  5:46   ` Michael Riesch
2022-09-14  5:46   ` Michael Riesch
2022-09-14 12:50   ` Chris Morgan [this message]
2022-09-14 12:50     ` Chris Morgan
2022-09-14 12:50     ` Chris Morgan
2022-09-15  7:16     ` Michael Riesch
2022-09-15  7:16       ` Michael Riesch
2022-09-15  7:16       ` Michael Riesch
2022-09-15 14:47       ` Chris Morgan
2022-09-15 14:47         ` Chris Morgan
2022-09-15 14:47         ` Chris Morgan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SN6PR06MB5342040C7772D95351DFD22FA5469@SN6PR06MB5342.namprd06.prod.outlook.com \
    --to=macromorgan@hotmail.com \
    --cc=cl@rock-chips.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frattaroli.nicolas@gmail.com \
    --cc=heiko@sntech.de \
    --cc=kishon@ti.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=macroalpha82@gmail.com \
    --cc=michael.riesch@wolfvision.net \
    --cc=pgwipeout@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.