All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: dri-devel@lists.freedesktop.org,
	Fabio Estevam <fabio.estevam@freescale.com>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	linux-renesas-soc@vger.kernel.org,
	Ulrich Hecht <ulrich.hecht@gmail.com>,
	Andy Yan <andy.yan@rock-chips.com>,
	Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Subject: Re: [PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling
Date: Thu, 05 Jan 2017 17:33:58 +0200	[thread overview]
Message-ID: <21211642.vKbn0SAu3E@avalon> (raw)
In-Reply-To: <df08a05b-1a17-688a-4710-eb1c9663c698@synopsys.com>

Hi Jose,

On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
> On 05-01-2017 12:29, Laurent Pinchart wrote:
> > On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
> >> On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> >>> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
> >>>> Instead of spreading version-dependent PHY power handling code around,
> >>>> group it in two functions to power the PHY on and off and use them
> >>>> through the driver.
> >>>> 
> >>>> Powering off the PHY at the beginning of the setup phase is currently
> >>>> split in two locations for first and second generation PHYs, group all
> >>>> the operations in the dw_hdmi_phy_init() function.
> >>> 
> >>> This changes the behaviour of the driver.
> >>> 
> >>>> +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> >>>> +{
> >>>> +	if (hdmi->phy->gen == 1) {
> >>>> +		dw_hdmi_phy_enable_tmds(hdmi, 0);
> >>>> +		dw_hdmi_phy_enable_powerdown(hdmi, true);
> >>>> +	} else {
> >>>> +		dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> >>>> +		dw_hdmi_phy_gen2_pddq(hdmi, 1);
> >>>> +	}
> >>>> +}
> >>>> @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> >>>> *hdmi)
> >>>> 
> >>>>  	if (!hdmi->phy_enabled)
> >>>>  	
> >>>>  		return;
> >>>> 
> >>>> -	dw_hdmi_phy_enable_tmds(hdmi, 0);
> >>>> -	dw_hdmi_phy_enable_powerdown(hdmi, true);
> >>>> -
> >>>> +	dw_hdmi_phy_power_off(hdmi);
> >>> 
> >>> This makes dw_hdmi_phy_disable() power down a gen2 phy.
> >>> 
> >>> The iMX6 has a DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY phy, which you list as a
> >>> gen2 phy.  I've been carrying this change for a while, which I've had
> >>> to revert (and finally expunge), as it causes problems on iMX6:
> >>> 
> >>> @@ -1112,6 +1112,14 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> >>> *hdmi)>
> >>> 
> >>>         if (!hdmi->phy_enabled)
> >>>         
> >>>                 return;
> >>> 
> >>> +       /* Actually set the phy into low power mode */
> >>> +       dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> >>> +
> >>> +       /* FIXME: We should wait for TX_READY to be deasserted */
> >>> +
> >>> +       dw_hdmi_phy_gen2_pddq(hdmi, 1);
> >>> +
> >>> +       /* This appears to have no effect on iMX6 */
> >>> 
> >>>         dw_hdmi_phy_enable_tmds(hdmi, 0);
> >>>         dw_hdmi_phy_enable_powerdown(hdmi, true);
> >>> 
> >>> So, I think your change here will cause problems for iMX6.
> >>> 
> >>> From what I remember, it seems that iMX6 has issues with RXSENSE/HPD
> >>> bouncing when the PHY is powered down.  I can't promise when I'll be
> >>> able to check for that again.
> >> 
> >> Indeed TX_READY must be low before asserting pddq.
> > 
> > The TX_READY signal is documented in the i.MX6 datasheet as being a PHY
> > output signal, but there seems to be no HDMI TX register from which its
> > state can be read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register
> > through I2C ? How long is the PHY expected to take to set TX_READY to 0 ?
> 
> TX_READY can be read from register 0x1A of phy, BIT(2) (through
> I2C).

That's what I thought, I'll poll that then. Do you have any idea how long it's 
supposed to take, to set an appropriate timeout ?

> Not sure if same offset for all phys though.

Most probably not, it would be too easy :-) I'll investigate (which will 
likely include lots of guesswork). If you can find any information about that 
(and especially about the MHL and HDMI 2.0 PHYs) that would be very 
appreciated, as I don't have access to any documentation that mentions a 
TX_READY bit for those.

-- 
Regards,

Laurent Pinchart

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	dri-devel@lists.freedesktop.org,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	linux-renesas-soc@vger.kernel.org,
	Ulrich Hecht <ulrich.hecht@gmail.com>,
	Andy Yan <andy.yan@rock-chips.com>,
	Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Subject: Re: [PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling
Date: Thu, 05 Jan 2017 17:33:58 +0200	[thread overview]
Message-ID: <21211642.vKbn0SAu3E@avalon> (raw)
In-Reply-To: <df08a05b-1a17-688a-4710-eb1c9663c698@synopsys.com>

Hi Jose,

On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
> On 05-01-2017 12:29, Laurent Pinchart wrote:
> > On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
> >> On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> >>> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
> >>>> Instead of spreading version-dependent PHY power handling code around,
> >>>> group it in two functions to power the PHY on and off and use them
> >>>> through the driver.
> >>>> 
> >>>> Powering off the PHY at the beginning of the setup phase is currently
> >>>> split in two locations for first and second generation PHYs, group all
> >>>> the operations in the dw_hdmi_phy_init() function.
> >>> 
> >>> This changes the behaviour of the driver.
> >>> 
> >>>> +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> >>>> +{
> >>>> +	if (hdmi->phy->gen == 1) {
> >>>> +		dw_hdmi_phy_enable_tmds(hdmi, 0);
> >>>> +		dw_hdmi_phy_enable_powerdown(hdmi, true);
> >>>> +	} else {
> >>>> +		dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> >>>> +		dw_hdmi_phy_gen2_pddq(hdmi, 1);
> >>>> +	}
> >>>> +}
> >>>> @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> >>>> *hdmi)
> >>>> 
> >>>>  	if (!hdmi->phy_enabled)
> >>>>  	
> >>>>  		return;
> >>>> 
> >>>> -	dw_hdmi_phy_enable_tmds(hdmi, 0);
> >>>> -	dw_hdmi_phy_enable_powerdown(hdmi, true);
> >>>> -
> >>>> +	dw_hdmi_phy_power_off(hdmi);
> >>> 
> >>> This makes dw_hdmi_phy_disable() power down a gen2 phy.
> >>> 
> >>> The iMX6 has a DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY phy, which you list as a
> >>> gen2 phy.  I've been carrying this change for a while, which I've had
> >>> to revert (and finally expunge), as it causes problems on iMX6:
> >>> 
> >>> @@ -1112,6 +1112,14 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> >>> *hdmi)>
> >>> 
> >>>         if (!hdmi->phy_enabled)
> >>>         
> >>>                 return;
> >>> 
> >>> +       /* Actually set the phy into low power mode */
> >>> +       dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> >>> +
> >>> +       /* FIXME: We should wait for TX_READY to be deasserted */
> >>> +
> >>> +       dw_hdmi_phy_gen2_pddq(hdmi, 1);
> >>> +
> >>> +       /* This appears to have no effect on iMX6 */
> >>> 
> >>>         dw_hdmi_phy_enable_tmds(hdmi, 0);
> >>>         dw_hdmi_phy_enable_powerdown(hdmi, true);
> >>> 
> >>> So, I think your change here will cause problems for iMX6.
> >>> 
> >>> From what I remember, it seems that iMX6 has issues with RXSENSE/HPD
> >>> bouncing when the PHY is powered down.  I can't promise when I'll be
> >>> able to check for that again.
> >> 
> >> Indeed TX_READY must be low before asserting pddq.
> > 
> > The TX_READY signal is documented in the i.MX6 datasheet as being a PHY
> > output signal, but there seems to be no HDMI TX register from which its
> > state can be read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register
> > through I2C ? How long is the PHY expected to take to set TX_READY to 0 ?
> 
> TX_READY can be read from register 0x1A of phy, BIT(2) (through
> I2C).

That's what I thought, I'll poll that then. Do you have any idea how long it's 
supposed to take, to set an appropriate timeout ?

> Not sure if same offset for all phys though.

Most probably not, it would be too easy :-) I'll investigate (which will 
likely include lots of guesswork). If you can find any information about that 
(and especially about the MHL and HDMI 2.0 PHYs) that would be very 
appreciated, as I don't have access to any documentation that mentions a 
TX_READY bit for those.

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-01-05 15:33 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-20  1:33 [PATCH v2 00/29] R-Car Gen3 HDMI output support Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 01/29] drm: bridge: dw-hdmi: Merge __hdmi_phy_i2c_write and hdmi_phy_i2c_write Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 02/29] drm: bridge: dw-hdmi: Remove unneeded arguments to bind/unbind functions Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 03/29] drm: bridge: dw-hdmi: Remove unused function parameter Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 04/29] drm: bridge: dw-hdmi: Embed drm_bridge in struct dw_hdmi Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 05/29] drm: bridge: dw-hdmi: Remove encoder field from " Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 06/29] drm: bridge: dw-hdmi: Don't forward HPD events to DRM core before attach Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 07/29] drm: bridge: dw-hdmi: Move IRQ and IO resource allocation to common code Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 08/29] drm: bridge: dw-hdmi: Reorder functions to prepare for next commit Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 09/29] drm: bridge: dw-hdmi: Create connector in the bridge attach operation Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 10/29] drm: bridge: dw-hdmi: Implement DRM bridge registration Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 11/29] drm: bridge: dw-hdmi: Remove PHY configuration resolution parameter Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 12/29] drm: bridge: dw-hdmi: Rename CONF0 SPARECTRL bit to SVSRET Laurent Pinchart
2016-12-20 10:58   ` Jose Abreu
2016-12-20 10:58     ` Jose Abreu
2016-12-20  1:33 ` [PATCH v2 13/29] drm: bridge: dw-hdmi: Reject invalid product IDs Laurent Pinchart
2016-12-20 10:59   ` Jose Abreu
2016-12-20 10:59     ` Jose Abreu
2016-12-20  1:33 ` [PATCH v2 14/29] drm: bridge: dw-hdmi: Detect AHB audio DMA using correct register Laurent Pinchart
2016-12-20 11:00   ` Jose Abreu
2016-12-20 11:00     ` Jose Abreu
2016-12-20  1:33 ` [PATCH v2 15/29] drm: bridge: dw-hdmi: Handle overflow workaround based on device version Laurent Pinchart
2016-12-20 11:32   ` Jose Abreu
2016-12-20 11:32     ` Jose Abreu
2016-12-20  1:33 ` [PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime Laurent Pinchart
2016-12-20 11:39   ` Jose Abreu
2016-12-20 11:39     ` Jose Abreu
2016-12-20 13:11     ` Laurent Pinchart
2016-12-20 15:01       ` Jose Abreu
2016-12-20 15:01         ` Jose Abreu
2017-01-05  0:15         ` Laurent Pinchart
2017-01-05  0:15           ` Laurent Pinchart
2017-01-05 10:33           ` Jose Abreu
2017-01-05 10:33             ` Jose Abreu
2017-01-05 11:44             ` Laurent Pinchart
2017-01-05 11:44               ` Laurent Pinchart
2017-01-05 14:27               ` Jose Abreu
2017-01-05 14:27                 ` Jose Abreu
2016-12-20  1:33 ` [PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling Laurent Pinchart
2016-12-20 11:45   ` Russell King - ARM Linux
2016-12-20 12:17     ` Jose Abreu
2016-12-20 12:17       ` Jose Abreu
2017-01-05 12:29       ` Laurent Pinchart
2017-01-05 15:06         ` Jose Abreu
2017-01-05 15:06           ` Jose Abreu
2017-01-05 15:33           ` Laurent Pinchart [this message]
2017-01-05 15:33             ` Laurent Pinchart
2017-01-06  1:48             ` Laurent Pinchart
2017-01-06  1:48               ` Laurent Pinchart
2017-01-06 10:07               ` Jose Abreu
2017-01-06 10:07                 ` Jose Abreu
2017-01-06 14:52                 ` Laurent Pinchart
2017-01-06 14:52                   ` Laurent Pinchart
2017-03-01 11:09           ` Laurent Pinchart
2017-03-01 11:09             ` Laurent Pinchart
2017-03-01 16:25             ` Jose Abreu
2017-03-01 16:25               ` Jose Abreu
2017-03-01 22:47               ` Laurent Pinchart
2017-03-01 22:47                 ` Laurent Pinchart
2016-12-20 13:50     ` Laurent Pinchart
2016-12-20 13:50       ` Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 18/29] drm: bridge: dw-hdmi: Move CSC configuration out of PHY code Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 19/29] drm: bridge: dw-hdmi: Add support for custom PHY configuration Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 20/29] drm: bridge: dw-hdmi: Remove device type from platform data Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 21/29] dt-bindings: display: dw-hdmi: Clean up DT bindings documentation Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 22/29] dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 23/29] drm: rcar-du: Add Gen3 HDMI encoder support Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 24/29] drm: rcar-du: Skip disabled outputs Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 25/29] drm: rcar-du: Add DPLL support Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 26/29] drm: rcar-du: Add HDMI outputs to R8A7795 device description Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 27/29] arm64: dts: r8a7795: Add HDMI encoder support Laurent Pinchart
2016-12-20  1:33 ` [PATCH v2 28/29] arm64: dts: r8a7795: salvator-x: Enable HDMI outputs Laurent Pinchart
2016-12-20  1:34 ` [PATCH v2 29/29] arm64: dts: r8a7795: salvator-x: Add DU1 and DU2 external dot clocks Laurent Pinchart

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=21211642.vKbn0SAu3E@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=andy.yan@rock-chips.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fabio.estevam@freescale.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=ulrich.hecht@gmail.com \
    --cc=vladimir_zapolskiy@mentor.com \
    /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.