From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40D3CC4363A for ; Tue, 27 Oct 2020 18:28:51 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B497A206C1 for ; Tue, 27 Oct 2020 18:28:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="GXhhe7uI"; dkim=temperror (0-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="XUmOhwuc"; dkim=temperror (0-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="dVg5tdUT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B497A206C1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=CsJ5m3SYzOyG0W+fPY9Ledu0XIC4bllza1rG6yFBZR0=; b=GXhhe7uIvvIVntRsadsOAuW7+ nipoYB3N6U9l+v/a/kcZdZUP24DgAIX1X9rpjZ6VPEcbefupryqtOuXk/c2OI+DVnEY08GUHkgWgB EePVuPGq1qIWjYRNaKuj2YVqIbkOp6aH09iJMfAqTqVeMyE2oCrFxtFEMZtoFuvKXd4zYXyJ88MKL fH+cGCvX8yYvit5H4gl4GXNI96fdh75ZUybt518Mhd0WKRrWUO4kp7EnAzAFJL49AdXLoXrTrRDu+ 18ovG3APDd9iuPdYd2nPL05lS3A4wOoH/sscfGZUSfQ7IP7xfMLEi9bngAFUsOACYi79/KnSnbkP1 Pe0NFfQgA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXThj-0001og-I2; Tue, 27 Oct 2020 18:28:19 +0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXThg-0001oF-JY for linux-arm-kernel@lists.infradead.org; Tue, 27 Oct 2020 18:28:17 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 2A9F25803DD; Tue, 27 Oct 2020 14:28:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 27 Oct 2020 14:28:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=dSgnQIa3tA1J3WQvwUkryDJy17/ cH7uUtmKx14vRB74=; b=XUmOhwucqRqwCMBBJ5y53w/bh0MvJJmlNvX3vSsqwMI qeEcHNVJ3rB7rfqcict3X+E3gqDjDvKhDcTS6tlKTVvrolSfRmXLVvl67z/3+Sr2 24kdLLi8flG6sqlsxonszl63zyQ+ISrb82gG4+0iro95IjGI6FdT2b69DnTk3SA5 ku+o8UbKvVyK85gF1z2AyM7ujnVAd0r1bnm9LwQu+rWzpYeraHObxiImqoSixZmw wwru3O5JhbezMWnS4njh2PUEzVhcfWOPic2H0mPuIkaNYjkhImGLupHVb6j/kIsS HA1QmZmKTaXkcUChdV7/Tkz9XU6/Hwk7IoMM6Ef+0OQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dSgnQI a3tA1J3WQvwUkryDJy17/cH7uUtmKx14vRB74=; b=dVg5tdUTdLWWDtOyTUFtBn OYQeP2fmPeQJLXBsZgySH0cjE8fjTZArR3+woJpzcdhJcZMrzxX5i9x8687Ssk2V C1SEhEAWVfuK4XiO/cGEcAGUP2/1ODuzL/2aevPhnM3rzy3+CpptIzWbiroAPN3j nCjL3a+9iR6cAHLle/VlOAVZdnzWgbfV5euJquIfE2rjyC7iuCNa1iy2Yo28GXyh h18aMjgxI6gwt1PLEWlhXSHP33McwFU5udoahj+dc2equNrMhSxa0qdD7xeLrE8I +dGqU9bGEhhjU7ml8arlOwKGcnNymqkOpbMLaxKHMq49FoxP5xSqaXUPrrFjT65g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeelgdduudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnheptdfggfelgeehieeuieegfefgueduudefheffhfejleekheefjeevveegueel ueefnecuffhomhgrihhnpehlihhnuhigqdhsuhhngihirdhorhhgnecukfhppeeltddrke elrdeikedrjeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 20FBB3280067; Tue, 27 Oct 2020 14:28:13 -0400 (EDT) Date: Tue, 27 Oct 2020 19:28:11 +0100 From: Maxime Ripard To: Paul Kocialkowski Subject: Re: [PATCH 02/14] phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI CSI-2 Message-ID: <20201027182811.j6372vdmls5yvhri@gilmour.lan> References: <20201023174546.504028-1-paul.kocialkowski@bootlin.com> <20201023174546.504028-3-paul.kocialkowski@bootlin.com> <20201026153857.iwkn4iusi2jy2yf4@gilmour.lan> <20201027092326.GB168350@aptenodytes> MIME-Version: 1.0 In-Reply-To: <20201027092326.GB168350@aptenodytes> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201027_142816_960272_C2E62AF5 X-CRM114-Status: GOOD ( 33.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org, Philipp Zabel , Kishon Vijay Abraham I , Thomas Petazzoni , Greg Kroah-Hartman , Helen Koike , linux-kernel@vger.kernel.org, Chen-Yu Tsai , Hans Verkuil , linux-sunxi@googlegroups.com, Rob Herring , Vinod Koul , Yong Deng , Sakari Ailus , Hans Verkuil , Mauro Carvalho Chehab , kevin.lhopital@hotmail.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Content-Type: multipart/mixed; boundary="===============5141619080324797534==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============5141619080324797534== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uqnhruvnsc2qrfvt" Content-Disposition: inline --uqnhruvnsc2qrfvt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Oct 27, 2020 at 10:23:26AM +0100, Paul Kocialkowski wrote: > On Mon 26 Oct 20, 16:38, Maxime Ripard wrote: > > On Fri, Oct 23, 2020 at 07:45:34PM +0200, Paul Kocialkowski wrote: > > > The Allwinner A31 D-PHY supports both Rx and Tx modes. While the latt= er > > > is already supported and used for MIPI DSI this adds support for the > > > former, to be used with MIPI CSI-2. > > >=20 > > > This implementation is inspired by the Allwinner BSP implementation. > >=20 > > Mentionning which BSP you took this from would be helpful >=20 > Sure! It's from the Github repo linked from https://linux-sunxi.org/V3s. > Would you like that I mention this URL explicitly or would it be enough to > mention "Allwinner's V3s Linux SDK" as they seem to call it? Yeah, that would be great > > > +static int sun6i_dphy_rx_power_on(struct sun6i_dphy *dphy) > > > +{ > > > + /* Physical clock rate is actually half of symbol rate with DDR. */ > > > + unsigned long mipi_symbol_rate =3D dphy->config.hs_clk_rate; > > > + unsigned long dphy_clk_rate; > > > + unsigned int rx_dly; > > > + unsigned int lprst_dly; > > > + u32 value; > > > + > > > + dphy_clk_rate =3D clk_get_rate(dphy->mod_clk); > > > + if (!dphy_clk_rate) > > > + return -1; > >=20 > > Returning -1 is weird here? >=20 > What do you think would be a more appropriate error code to return? > It looks like some other drivers return -EINVAL when that happens (but ma= ny > don't do the check). Yeah, EINVAL at least is better than ENOPERM=20 > > > + > > > + /* Hardcoded timing parameters from the Allwinner BSP. */ > > > + regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME0_REG, > > > + SUN6I_DPHY_RX_TIME0_HS_RX_SYNC(255) | > > > + SUN6I_DPHY_RX_TIME0_HS_RX_CLK_MISS(255) | > > > + SUN6I_DPHY_RX_TIME0_LP_RX(255)); > > > + > > > + /* > > > + * Formula from the Allwinner BSP, with hardcoded coefficients > > > + * (probably internal divider/multiplier). > > > + */ > > > + rx_dly =3D 8 * (unsigned int)(dphy_clk_rate / (mipi_symbol_rate / 8= )); > > > + > > > + /* > > > + * The Allwinner BSP has an alternative formula for LP_RX_ULPS_WP: > > > + * lp_ulps_wp_cnt =3D lp_ulps_wp_ms * lp_clk / 1000 > > > + * but does not use it and hardcodes 255 instead. > > > + */ > > > + regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME1_REG, > > > + SUN6I_DPHY_RX_TIME1_RX_DLY(rx_dly) | > > > + SUN6I_DPHY_RX_TIME1_LP_RX_ULPS_WP(255)); > > > + > > > + /* HS_RX_ANA0 value is hardcoded in the Allwinner BSP. */ > > > + regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME2_REG, > > > + SUN6I_DPHY_RX_TIME2_HS_RX_ANA0(4)); > > > + > > > + /* > > > + * Formula from the Allwinner BSP, with hardcoded coefficients > > > + * (probably internal divider/multiplier). > > > + */ > > > + lprst_dly =3D 4 * (unsigned int)(dphy_clk_rate / (mipi_symbol_rate = / 2)); > > > + > > > + regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME3_REG, > > > + SUN6I_DPHY_RX_TIME3_LPRST_DLY(lprst_dly)); > > > + > > > + /* Analog parameters are hardcoded in the Allwinner BSP. */ > > > + regmap_write(dphy->regs, SUN6I_DPHY_ANA0_REG, > > > + SUN6I_DPHY_ANA0_REG_PWS | > > > + SUN6I_DPHY_ANA0_REG_SLV(7) | > > > + SUN6I_DPHY_ANA0_REG_SFB(2)); > > > + > > > + regmap_write(dphy->regs, SUN6I_DPHY_ANA1_REG, > > > + SUN6I_DPHY_ANA1_REG_SVTT(4)); > > > + > > > + regmap_write(dphy->regs, SUN6I_DPHY_ANA4_REG, > > > + SUN6I_DPHY_ANA4_REG_DMPLVC | > > > + SUN6I_DPHY_ANA4_REG_DMPLVD(1)); > > > + > > > + regmap_write(dphy->regs, SUN6I_DPHY_ANA2_REG, > > > + SUN6I_DPHY_ANA2_REG_ENIB); > > > + > > > + regmap_write(dphy->regs, SUN6I_DPHY_ANA3_REG, > > > + SUN6I_DPHY_ANA3_EN_LDOR | > > > + SUN6I_DPHY_ANA3_EN_LDOC | > > > + SUN6I_DPHY_ANA3_EN_LDOD); > > > + > > > + /* > > > + * Delay comes from the Allwinner BSP, likely for internal regulator > > > + * ramp-up. > > > + */ > > > + udelay(3); > > > + > > > + value =3D SUN6I_DPHY_RX_CTL_EN_DBC | SUN6I_DPHY_RX_CTL_RX_CLK_FORCE; > > > + > > > + /* > > > + * Rx data lane force-enable bits are used as regular RX enable by = the > > > + * Allwinner BSP. > > > + */ > > > + if (dphy->config.lanes >=3D 1) > > > + value |=3D SUN6I_DPHY_RX_CTL_RX_D0_FORCE; > > > + if (dphy->config.lanes >=3D 2) > > > + value |=3D SUN6I_DPHY_RX_CTL_RX_D1_FORCE; > > > + if (dphy->config.lanes >=3D 3) > > > + value |=3D SUN6I_DPHY_RX_CTL_RX_D2_FORCE; > > > + if (dphy->config.lanes =3D=3D 4) > > > + value |=3D SUN6I_DPHY_RX_CTL_RX_D3_FORCE; > > > + > > > + regmap_write(dphy->regs, SUN6I_DPHY_RX_CTL_REG, value); > > > + > > > + regmap_write(dphy->regs, SUN6I_DPHY_GCTL_REG, > > > + SUN6I_DPHY_GCTL_LANE_NUM(dphy->config.lanes) | > > > + SUN6I_DPHY_GCTL_EN); > > > + > > > + return 0; > > > +} > > > + > > > +static int sun6i_dphy_power_on(struct phy *phy) > > > +{ > > > + struct sun6i_dphy *dphy =3D phy_get_drvdata(phy); > > > + > > > + switch (dphy->submode) { > > > + case PHY_MIPI_DPHY_SUBMODE_TX: > > > + return sun6i_dphy_tx_power_on(dphy); > > > + case PHY_MIPI_DPHY_SUBMODE_RX: > > > + return sun6i_dphy_rx_power_on(dphy); > > > + default: > > > + return -EINVAL; > > > + } > > > +} > > > + > >=20 > > Can one call power_on before set_mode? >=20 > I didn't find anything indicating this is illegal. What would happen here= is > that the D-PHY would be configured to PHY_MIPI_DPHY_SUBMODE_TX (submode = =3D=3D 0) > at power-on if set_mode is not called before. >=20 > I think it's fair to expect that it's too late to change the mode once th= e PHY > was powered on. Maybe we should return -EBUSY on set_mode when power on w= as > already requested? Or maybe we can just clarify it in the framework/function documentation Maxime --uqnhruvnsc2qrfvt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX5hmuwAKCRDj7w1vZxhR xeyQAQD8UUtAF93oDhvysOz/Nj17EEhOoBwmmzBNGTtdCLRtUgD9EsftZeY/+IOA Kzp6yDaCvfPfojb2leh+z+S5NCYPxQ4= =HLIM -----END PGP SIGNATURE----- --uqnhruvnsc2qrfvt-- --===============5141619080324797534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============5141619080324797534==--