From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752460AbcBAGdA (ORCPT ); Mon, 1 Feb 2016 01:33:00 -0500 Received: from down.free-electrons.com ([37.187.137.238]:50461 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751525AbcBAGc7 (ORCPT ); Mon, 1 Feb 2016 01:32:59 -0500 Date: Mon, 1 Feb 2016 07:32:56 +0100 From: Maxime Ripard To: =?iso-8859-1?Q?Andr=E9?= Przywara Cc: Lee Jones , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel@stlinux.com, s.hauer@pengutronix.de, sboyd@codeaurora.org, geert@linux-m68k.org, mturquette@baylibre.com, maxime.coquelin@st.com Subject: Re: [PATCH 3/3] clk: Provide OF helper to mark clocks as CRITICAL Message-ID: <20160201063256.GE32462@lukather> References: <1453127331-20616-1-git-send-email-lee.jones@linaro.org> <1453127331-20616-4-git-send-email-lee.jones@linaro.org> <56A95811.8010200@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T6xhMxlHU34Bk0ad" Content-Disposition: inline In-Reply-To: <56A95811.8010200@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --T6xhMxlHU34Bk0ad Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Andre, On Wed, Jan 27, 2016 at 11:51:45PM +0000, Andr=E9 Przywara wrote: > Hi, >=20 > On 18/01/16 14:28, Lee Jones wrote: > > This call matches clocks which have been marked as critical in DT > > and sets the appropriate flag. These flags can then be used to > > mark the clock core flags appropriately prior to registration. >=20 > I like the idea of having a generic property very much. Also this solves > a problem I have in a very elegant way. Not really. It has a significant set of drawbacks that we already detailed in the initial thread, which are mostly related to the fact that the clocks are to be left on is something that totally depends on the software support in the kernel. Some clocks should be reported as critical because they are simply missing a driver for it, some should be because the driver for it as not been compiled, some should because we don't have the proper clocks drivers yet for one of their downstream clocks. Basically, it all boils down to this: some clocks should never ever be shutdown because , and I believe it's the case Lee is in. But most of the current code that would use it might, and might even need at some point to shut down such a clock. Mike's solution with the flags + handover was solving all this, I'm not sure why he's not pushed it forward. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --T6xhMxlHU34Bk0ad Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWrvwYAAoJEBx+YmzsjxAgAs4QAIjS5E6aHmVlLylPcg4BCFVB HK4eAMbQ7dcxFrfCkB/H440jMjzsk7rlfeh7JfAXBW7jaDut+Uo09A0glLChMZq3 DAPIK/u/rtTe64/JyJnACZH5VOUYAw/1eJLA3iOjpuFHEboqlHgRWE8afSxHH3Ov EmtQ5eJuIcMIXqm0nM0E4eAEKAIB4UHw6OrKIcrqip2ZtaReXUG7XXC933ncTMy0 fadu6ig1yjkpnWqOqd5QuDAI7rA0quP1cUjO4lDGvhHJEGkSeP/8eEEp2dONQVbN lJcsDQrf56QJD2DNUwaOp7OambE8sDkR6gKDPPfbKp+go/0flPPp8DPlgY55wPms ChR7nyPrn7+0PndJeyM8HPIGD2sDPzRbRczH8oEI70nBpEQDCVPfcEusYsfVyW9p mpFXcHPQdRBBZ1X30SSAnRg9A8SrcZ3VYDMoUjEs87uwlGMmeGBTn5UCxOvg5qWv RPkLOZKlniVt8g0XqgnxMWXNgl1lQDt3VGbDRLm/Eu5kEzqRa4CajH2y9yPbe5dc H/4e2dTmh/bug9VZ/j+Ka632QkwXlTHjv529Me6/GcGlVG5P6B/qQUWAFOEt5eNJ ckQpDwwOhzMxZAJXfpS/qRkofyeA2ONsNNjnKQ2bdtGSnem6wM5qtf+HjPWInzJ8 7r61gUUwC+2BLhMxcDXL =3BJl -----END PGP SIGNATURE----- --T6xhMxlHU34Bk0ad--