From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Re: [PATCH v2 2/9] phy: Add configuration interface Date: Wed, 14 Nov 2018 11:51:52 +0100 Message-ID: <20181114105152.sgk454t34hmzstkn@flea> References: <4d0506aa0a61d234610b42a268a8326d9ea18466.1541516029.git-series.maxime.ripard@bootlin.com> <3a9a28df-8139-1036-a884-0de64aa07df1@ti.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1516983001==" Return-path: Received: from mail.bootlin.com (mail.bootlin.com [62.4.15.54]) by gabe.freedesktop.org (Postfix) with ESMTP id 8F49E6E4F3 for ; Wed, 14 Nov 2018 10:51:53 +0000 (UTC) In-Reply-To: <3a9a28df-8139-1036-a884-0de64aa07df1@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Kishon Vijay Abraham I Cc: Krzysztof Witos , Rafal Ciepiela , Boris Brezillon , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Chen-Yu Tsai , Laurent Pinchart , Thomas Petazzoni , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org --===============1516983001== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="32jb3i42ot3gk2nm" Content-Disposition: inline --32jb3i42ot3gk2nm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Kishon On Mon, Nov 12, 2018 at 03:32:25PM +0530, Kishon Vijay Abraham I wrote: > On 06/11/18 8:24 PM, Maxime Ripard wrote: > > The phy framework is only allowing to configure the power state of the = PHY > > using the init and power_on hooks, and their power_off and exit > > counterparts. > >=20 > > While it works for most, simple, PHYs supported so far, some more advan= ced > > PHYs need some configuration depending on runtime parameters. These PHYs > > have been supported by a number of means already, often by using ad-hoc > > drivers in their consumer drivers. > >=20 > > That doesn't work too well however, when a consumer device needs to deal > > with multiple PHYs, or when multiple consumers need to deal with the sa= me > > PHY (a DSI driver and a CSI driver for example). > >=20 > > So we'll add a new interface, through two funtions, phy_validate and > > phy_configure. The first one will allow to check that a current > > configuration, for a given mode, is applicable. It will also allow the = PHY > > driver to tune the settings given as parameters as it sees fit. > >=20 > > phy_configure will actually apply that configuration in the phy itself. > >=20 > > Signed-off-by: Maxime Ripard > > --- > > drivers/phy/phy-core.c | 61 +++++++++++++++++++++++++++++++++++++++++= +- > > include/linux/phy/phy.h | 58 ++++++++++++++++++++++++++++++++++++++++- > > 2 files changed, 119 insertions(+) > >=20 > > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c > > index 35fd38c5a4a1..7bd3ed65c708 100644 > > --- a/drivers/phy/phy-core.c > > +++ b/drivers/phy/phy-core.c > > @@ -408,6 +408,67 @@ int phy_calibrate(struct phy *phy) > > EXPORT_SYMBOL_GPL(phy_calibrate); > > =20 > > /** > > + * phy_configure() - Changes the phy parameters > > + * @phy: the phy returned by phy_get() > > + * @opts: New configuration to apply > > + * > > + * Used to change the PHY parameters. phy_init() must have been called > > + * on the phy. The configuration will be applied on the current phy > > + * mode, that can be changed using phy_set_mode(). > > + * > > + * Returns: 0 if successful, an negative error code otherwise > > + */ > > +int phy_configure(struct phy *phy, union phy_configure_opts *opts) > > +{ > > + int ret; > > + > > + if (!phy) > > + return -EINVAL; > > + > > + if (!phy->ops->configure) > > + return -EOPNOTSUPP; > > + > > + mutex_lock(&phy->mutex); > > + ret =3D phy->ops->configure(phy, opts); > > + mutex_unlock(&phy->mutex); > > + > > + return ret; > > +} >=20 > EXPORT_SYMBOL_GPL is missing here and below. Consider it done. > > + > > +/** > > + * phy_validate() - Checks the phy parameters > > + * @phy: the phy returned by phy_get() > > + * @mode: phy_mode the configuration is applicable to. > > + * @opts: Configuration to check > > + * > > + * Used to check that the current set of parameters can be handled by > > + * the phy. Implementations are free to tune the parameters passed as > > + * arguments if needed by some implementation detail or > > + * constraints. It will not change any actual configuration of the > > + * PHY, so calling it as many times as deemed fit will have no side > > + * effect. > > + * > > + * Returns: 0 if successful, an negative error code otherwise > > + */ > > +int phy_validate(struct phy *phy, enum phy_mode mode, > > + union phy_configure_opts *opts) >=20 > We are planning to switch to mode/submode combination [1], so this might = have > to change. Yes, I'm aware of that. If needed, it shouldn't be too hard to rework. Maxime --=20 Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --32jb3i42ot3gk2nm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCW+v+SAAKCRDj7w1vZxhR xd4KAQCgTxP0Iny1S4qIKFkd8A9D3wnv7pIQyNYHX9WZ3veABAD/dx5YKRWQmCSz Jg6veFo/A77Cfj3GCfGHzvgtgD3I4gY= =XbmS -----END PGP SIGNATURE----- --32jb3i42ot3gk2nm-- --===============1516983001== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1516983001==--