From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Saenz Julienne Subject: Re: [PATCH] i2c: bcm2835: Model Divider in CCF Date: Mon, 06 May 2019 17:59:12 +0200 Message-ID: <6436b4f65565e3fca6827b1c6c0b95f81b099d98.camel@suse.de> References: <20190505034339.30778-1-nh6z@nh6z.net> <610c7594-85c9-72db-63a6-6e632e9586aa@i2se.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8055653226505597447==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Florian Fainelli , Stefan Wahren , Annaliese McDermond , eric@anholt.net, wsa@the-dreams.de, linux-i2c@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org Cc: team@nwdigitalradio.com List-Id: linux-i2c@vger.kernel.org --===============8055653226505597447== Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-NF/oAISSXjVajL9Q6zli" --=-NF/oAISSXjVajL9Q6zli Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2019-05-05 at 10:13 -0700, Florian Fainelli wrote: >=20 > On 5/5/2019 3:36 AM, Stefan Wahren wrote: > > Hi Annaliese, > >=20 > > Am 05.05.19 um 05:43 schrieb Annaliese McDermond: > > > Model the I2C bus clock divider as a part of the Core Clock Framework= . > > > Primarily this removes the clk_get_rate() call from each transfer. > > > This call causes problems for slave drivers that themselves have > > > internal clock components that are controlled by an I2C interface. > > > When the slave's internal clock component is prepared, the prepare > > > lock is obtained, and it makes calls to the I2C subsystem to > > > command the hardware to activate the clock. In order to perform > > > the I2C transfer, this driver sets the divider, which requires > > > it to get the parent clock rate, which it does with clk_get_rate(). > > > Unfortunately, this function will try to take the clock prepare > > > lock, which is already held by the slave's internal clock calls > > > creating a deadlock. > >=20 > > i think i understand the problem, but could you please explain the > > specific use case where this happend? > >=20 > > I suspect bcm2835 is not the only platform which is affected, so it > > would be better to fix this in general. >=20 > Agreed, if you could identify i2c bus drivers that support changing the > bus clock and move the registration of the bus 'struct clk' into the i2c > core that would scale a lot better. For the record, some time ago I asked for directions on how to properly han= dle asyncronous clk rate changes on devices like this and the clk mantainers' proposed solution[1] needed something similar to what Annaliese is proposin= g. That said, I can think of more subsystems that could benefit of a generic solution for this. I'm pretty sure SPI would, but also MMC, UARTs, and othe= rs. [1] https://www.spinics.net/lists/linux-clk/msg36937.html --=-NF/oAISSXjVajL9Q6zli Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEErOkkGDHCg2EbPcGjlfZmHno8x/4FAlzQWdAACgkQlfZmHno8 x/6IsAf+ID13VCoGqWG4174whG3Ks3+bn8WWuz8UlPe23RRO9vXQSurDN9839eIN Hyd9h8CNClLc1TCNJmaxKURycfwavKNuedfa+WxZXVV4iNLbVJpRjtCWsYmcuEY6 BFR+d2hpi7xN8CwK7NlXc64Yim81OUdn3ph0sONRn+PJDIOeJfZIfUpueibMQA/B K4JDfPBaMoACZ9piTLL0NsTHOfjc4MRmksFPMxsYr3KnfZXy9lm0haUZPrIrNVni egDuNK0ZstLwiaGPtXrUVl8QaRSZFNWaB/tY4oZ4bmDwPkxOtYzz4ZOlFupvg1aK vn2pwH8TuTDQsgizLuKOOnF2GzCiHQ== =fidG -----END PGP SIGNATURE----- --=-NF/oAISSXjVajL9Q6zli-- --===============8055653226505597447== 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 --===============8055653226505597447==-- 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=-0.7 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 DE8A7C04A6B for ; Mon, 6 May 2019 15:59:27 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 A62C32087F for ; Mon, 6 May 2019 15:59:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="sVBlgVy+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A62C32087F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: MIME-Version:References:In-Reply-To:Date:To:From:Subject:Message-ID: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=fZbt6ArjwDET8MdJWqa9VtSuDIEGOM85+87E+9OlhwQ=; b=sVBlgVy+laG4q0rhL4ZMsylq3 oICGLlJKGoUBASIJSmZkGXriPmfRXDRN58/XJgOy5ICd5UUygxoW8G6XF/2y8lmXjzrYan23SOF+k ySPKUxtxkEMLuPywKL3rSi7kftDvm+Lx138c/K9YRkGFrcns6k+Zv5MShNu6zJf/lSBlts6BUGqDd Ypw/mau124FkjvupgFX6RgLrMceIwbOG6PhmHmTZddOnOyRJwXKPLryTmgLU3ZR0mdxqT6aIkN7oG 0cdgDbwN67DElmdx8gmNG9rsejA0KlyUcm9f9XxZpkC7S69F/9HsFYHvhfmflTkxtIZZrrF+L8GoZ NotHF2AlA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hNg1Q-0001al-U3; Mon, 06 May 2019 15:59:20 +0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hNg1L-0001Tl-7h; Mon, 06 May 2019 15:59:17 +0000 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D03DCABD7; Mon, 6 May 2019 15:59:13 +0000 (UTC) Message-ID: <6436b4f65565e3fca6827b1c6c0b95f81b099d98.camel@suse.de> Subject: Re: [PATCH] i2c: bcm2835: Model Divider in CCF From: Nicolas Saenz Julienne To: Florian Fainelli , Stefan Wahren , Annaliese McDermond , eric@anholt.net, wsa@the-dreams.de, linux-i2c@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org Date: Mon, 06 May 2019 17:59:12 +0200 In-Reply-To: References: <20190505034339.30778-1-nh6z@nh6z.net> <610c7594-85c9-72db-63a6-6e632e9586aa@i2se.com> User-Agent: Evolution 3.30.5 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190506_085915_499213_94649DFA X-CRM114-Status: GOOD ( 21.00 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: team@nwdigitalradio.com Content-Type: multipart/mixed; boundary="===============8055653226505597447==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============8055653226505597447== Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-NF/oAISSXjVajL9Q6zli" --=-NF/oAISSXjVajL9Q6zli Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2019-05-05 at 10:13 -0700, Florian Fainelli wrote: >=20 > On 5/5/2019 3:36 AM, Stefan Wahren wrote: > > Hi Annaliese, > >=20 > > Am 05.05.19 um 05:43 schrieb Annaliese McDermond: > > > Model the I2C bus clock divider as a part of the Core Clock Framework= . > > > Primarily this removes the clk_get_rate() call from each transfer. > > > This call causes problems for slave drivers that themselves have > > > internal clock components that are controlled by an I2C interface. > > > When the slave's internal clock component is prepared, the prepare > > > lock is obtained, and it makes calls to the I2C subsystem to > > > command the hardware to activate the clock. In order to perform > > > the I2C transfer, this driver sets the divider, which requires > > > it to get the parent clock rate, which it does with clk_get_rate(). > > > Unfortunately, this function will try to take the clock prepare > > > lock, which is already held by the slave's internal clock calls > > > creating a deadlock. > >=20 > > i think i understand the problem, but could you please explain the > > specific use case where this happend? > >=20 > > I suspect bcm2835 is not the only platform which is affected, so it > > would be better to fix this in general. >=20 > Agreed, if you could identify i2c bus drivers that support changing the > bus clock and move the registration of the bus 'struct clk' into the i2c > core that would scale a lot better. For the record, some time ago I asked for directions on how to properly han= dle asyncronous clk rate changes on devices like this and the clk mantainers' proposed solution[1] needed something similar to what Annaliese is proposin= g. That said, I can think of more subsystems that could benefit of a generic solution for this. I'm pretty sure SPI would, but also MMC, UARTs, and othe= rs. [1] https://www.spinics.net/lists/linux-clk/msg36937.html --=-NF/oAISSXjVajL9Q6zli Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEErOkkGDHCg2EbPcGjlfZmHno8x/4FAlzQWdAACgkQlfZmHno8 x/6IsAf+ID13VCoGqWG4174whG3Ks3+bn8WWuz8UlPe23RRO9vXQSurDN9839eIN Hyd9h8CNClLc1TCNJmaxKURycfwavKNuedfa+WxZXVV4iNLbVJpRjtCWsYmcuEY6 BFR+d2hpi7xN8CwK7NlXc64Yim81OUdn3ph0sONRn+PJDIOeJfZIfUpueibMQA/B K4JDfPBaMoACZ9piTLL0NsTHOfjc4MRmksFPMxsYr3KnfZXy9lm0haUZPrIrNVni egDuNK0ZstLwiaGPtXrUVl8QaRSZFNWaB/tY4oZ4bmDwPkxOtYzz4ZOlFupvg1aK vn2pwH8TuTDQsgizLuKOOnF2GzCiHQ== =fidG -----END PGP SIGNATURE----- --=-NF/oAISSXjVajL9Q6zli-- --===============8055653226505597447== 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 --===============8055653226505597447==--