lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <PAXPR04MB9448D68A5CA9755036E9B23DF42F2@PAXPR04MB9448.eurprd04.prod.outlook.com>
Date: Tue, 26 Nov 2024 14:12:19 +0000
From: Sandor Yu <sandor.yu@....com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: "andrzej.hajda@...el.com" <andrzej.hajda@...el.com>,
	"neil.armstrong@...aro.org" <neil.armstrong@...aro.org>, Laurent Pinchart
	<laurent.pinchart@...asonboard.com>, "jonas@...boo.se" <jonas@...boo.se>,
	"jernej.skrabec@...il.com" <jernej.skrabec@...il.com>, "airlied@...il.com"
	<airlied@...il.com>, "daniel@...ll.ch" <daniel@...ll.ch>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
	"shawnguo@...nel.org" <shawnguo@...nel.org>, "s.hauer@...gutronix.de"
	<s.hauer@...gutronix.de>, "festevam@...il.com" <festevam@...il.com>,
	"vkoul@...nel.org" <vkoul@...nel.org>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-phy@...ts.infradead.org"
	<linux-phy@...ts.infradead.org>, "mripard@...nel.org" <mripard@...nel.org>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>, dl-linux-imx
	<linux-imx@....com>, Oliver Brown <oliver.brown@....com>,
	"alexander.stein@...tq-group.com" <alexander.stein@...tq-group.com>,
	"sam@...nborg.org" <sam@...nborg.org>
Subject: RE: [EXT] Re: [PATCH v18 6/8] phy: freescale: Add DisplayPort/HDMI
 Combo-PHY driver for i.MX8MQ

 
> 
> On Tue, Nov 05, 2024 at 02:05:51PM +0000, Sandor Yu wrote:
> > >
> > > On Tue, Oct 29, 2024 at 02:02:14PM +0800, Sandor Yu wrote:
> > > > Add Cadence HDP-TX DisplayPort and HDMI PHY driver for i.MX8MQ.
> > > >
> > > > Cadence HDP-TX PHY could be put in either DP mode or HDMI mode
> > > > base on the configuration chosen.
> > > > DisplayPort or HDMI PHY mode is configured in the driver.
> > > >
> > > > Signed-off-by: Sandor Yu <Sandor.yu@....com>
> > > > Signed-off-by: Alexander Stein <alexander.stein@...tq-group.com>
> > > > ---
> > > > v17->v18:
> > > > - fix build error as code rebase to latest kernel version.
> > > >
> > > >  drivers/phy/freescale/Kconfig                |   10 +
> > > >  drivers/phy/freescale/Makefile               |    1 +
> > > >  drivers/phy/freescale/phy-fsl-imx8mq-hdptx.c | 1337
> > > ++++++++++++++++++
> > > >  3 files changed, 1348 insertions(+)  create mode 100644
> > > > drivers/phy/freescale/phy-fsl-imx8mq-hdptx.c
> > > >
> > > > diff --git a/drivers/phy/freescale/Kconfig
> > > > b/drivers/phy/freescale/Kconfig index dcd9acff6d01a..2b1210367b31c
> > > > 100644
> > > > --- a/drivers/phy/freescale/Kconfig
> > > > +++ b/drivers/phy/freescale/Kconfig
> 
> [...]
> 
> I'm sorry, my email client cut the email.
> 
> > > > +static int cdns_hdptx_dp_configure(struct phy *phy,
> > > > +                                union phy_configure_opts
> *opts) {
> > > > +     struct cdns_hdptx_phy *cdns_phy = phy_get_drvdata(phy);
> > > > +
> > > > +     cdns_phy->dp.link_rate = opts->dp.link_rate;
> > > > +     cdns_phy->dp.lanes = opts->dp.lanes;
> > >
> > > Shouldn't this be conditional on set_rate / set_lanes ?
> >
> > PHY do not support reconfigure link rate and lane count.
> 
> So, you don't support reconfiguring the rate / count, but you still copy the new
> rate and lanes into your driver data. That sounds strange.

The PHY will use link rate and lane count to configure its registers

> 
> [...]
> 
> >
> > >
> > > > +
> > > > +static int cdns_hdptx_phy_set_mode(struct phy *phy, enum phy_mode
> > > mode, int submode)
> > > > +{
> > > > +     struct cdns_hdptx_phy *cdns_phy = phy_get_drvdata(phy);
> > > > +     int ret = 0;
> > > > +
> > > > +     if (mode == PHY_MODE_DP) {
> > > > +             hdptx_dp_phy_ref_clock_type(cdns_phy);
> > > > +
> > > > +             /* PHY power up */
> > > > +             ret = hdptx_dp_phy_power_up(cdns_phy);
> > > > +             if (ret < 0)
> > > > +                     return ret;
> > > > +
> > > > +             hdptx_dp_aux_cfg(cdns_phy);
> > >
> > > Why? Don't power up the PHY if you haven't been told to.
> >
> > Power on the PHY to enable DP AUX, which is necessary for reading EDID
> and training the link.
> 
> Call phy_power_on() from the DP driver.

OK.

> 
> >
> > >
> > > > +     } else if (mode != PHY_MODE_HDMI) {
> > > > +             dev_err(&phy->dev, "Invalid PHY mode: %u\n", mode);
> > > > +             return -EINVAL;
> > > > +     }
> > > > +
> > > > +     return ret;
> > > > +}
> > > > +
> > > > +static int cdns_hdptx_hdmi_configure(struct phy *phy,
> > > > +                                  union phy_configure_opts
> > > *opts)
> > > > +{
> > > > +     struct cdns_hdptx_phy *cdns_phy = phy_get_drvdata(phy);
> > > > +     int ret;
> > > > +
> > > > +     cdns_phy->hdmi.tmds_char_rate = opts->hdmi.tmds_char_rate;
> > > > +
> > > > +     /* Check HDMI FW alive before HDMI PHY init */
> > > > +     ret = hdptx_phy_check_alive(cdns_phy);
> > > > +     if (!ret) {
> > > > +             dev_err(cdns_phy->dev, "NO HDMI FW running\n");
> > > > +             return -ENXIO;
> > > > +     }
> > > > +
> > > > +     /* Configure PHY */
> > > > +     if (hdptx_hdmi_phy_cfg(cdns_phy,
> > > > + cdns_phy->hdmi.tmds_char_rate)
> > > < 0) {
> > > > +             dev_err(cdns_phy->dev, "failed to set phy pclock\n");
> > > > +             return -EINVAL;
> > > > +     }
> > > > +
> > > > +     ret = hdptx_hdmi_phy_power_up(cdns_phy);
> > >
> > > it seems to be all over the place :-(
> >
> > The PHY has different power-up rules depending on whether it's in DP or
> HDMI mode.
> > In DP mode, it needs to power up first to enable DP AUX.
> > In HDMI mode, it can power up last.
> 
> The main question is why are you powering the PHY from the configure path
> at all? There is a phy_power_on() API which should be used by your HDMI /
> DP driver instead of handling that in an automagic way.
> 

OK, I will remove PHY power state change code in PHY driver.
Controller driver will call phy_power_on()/phy_power_off() to management the PHY power states

Best regards
Sandor

> >
> 
> --
> With best wishes
> Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ