From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752560AbcELSXW (ORCPT ); Thu, 12 May 2016 14:23:22 -0400 Received: from anholt.net ([50.246.234.109]:42032 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751693AbcELSXU (ORCPT ); Thu, 12 May 2016 14:23:20 -0400 From: Eric Anholt To: Martin Sperl Cc: Michael Turquette , Stephen Boyd , linux-kernel@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 0/3] clk: bcm2835: critical clocks and parent selection In-Reply-To: References: <1462842090-2017-1-git-send-email-eric@anholt.net> <5731B8BA.30402@martin.sperl.org> <87a8jxyfua.fsf@eliezer.anholt.net> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 12 May 2016 11:23:15 -0700 Message-ID: <87oa8b9lv0.fsf@eliezer.anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Martin Sperl writes: >> On 10.05.2016, at 19:37, Eric Anholt wrote: >>=20 >> Martin Sperl writes: >>> and also hsm (probably hardware security module): >>> root@raspcm:~# cat /sys/kernel/debug/clk/hsm/regdump >>> ctl =3D 0x000002d6 >>> div =3D 0x000030e0 >>> root@raspcm:~# cat /sys/kernel/debug/clk/hsm/clk_rate >>> 163551916 >>=20 >> That's the HDMI state machine (there's even a comment saying so), >> controlled by the vc4 driver. >>=20 >>> So turning plld off stops sdram and hsm - at least that is my >>> interpretation. >>>=20 >>> This means we need to define a clock property in firmware or >>> we need a ram node making use of "mmio-sram" maybe? >>>=20 >>> Marking sdram as "critical" or "hand_off" could also solve that >>> for the moment (but it does not solve all the other hidden >>> clock dependencies of the firmware) >>=20 >> If there are other hidden dependencies, then we should figure them out. > > But strangely the sdram (plus the below) is the only one with > plld that is enabled (unless it is one of the clocks we have not > added to the kernel side yet) > > Maybe there is something that derives directly from plld_core > or any of the other plld-dividers? Nothing I can find. > Core would indicate anything central to the videocore... > Anyway both plld_core as well as plld_per ad well as both > Pll_dsi that are running by default (but I doubt that the > Dsi would be relevant) > > I guess you are in a better situation to figure out which > hidden HW blocks uses plld... > >>=20 >>> --- a/drivers/clk/bcm/clk-bcm2835.c >>> +++ b/drivers/clk/bcm/clk-bcm2835.c >>> @@ -1655,7 +1655,8 @@ static const struct bcm2835_clk_desc=20 >>> clk_desc_array[] =3D { >>> .ctl_reg =3D CM_SDCCTL, >>> .div_reg =3D CM_SDCDIV, >>> .int_bits =3D 6, >>> - .frac_bits =3D 0), >>> + .frac_bits =3D 0, >>> + .flags =3D CLK_IS_CRITICAL), >>> [BCM2835_CLOCK_V3D] =3D REGISTER_VPU_CLK( >>> .name =3D "v3d", >>> .ctl_reg =3D CM_V3DCTL, >>=20 >> The Pi foundation folks believe that the cprman SDRAM clock isn't ever >> used (there's a separate PLL in the SDRAM controller, and cprman is only >> intended for unused low-power states), and at least in your sample of >> the reg, it's not enabled. Instead of grepping for clk_enable_count, it > See my comment above - it must be configured for some reason > during the boot process by the firmware . You have to write the register to configure the sdram controller's clock parent. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJXNMoUAAoJELXWKTbR/J7oywkP/jJpeXQ2TOVweNyv3PHEcZOM etsZNnKi4+W1PoR0NbLqsn7H1fglO9Av8CCc649k+h1nW21ToM1gRVP7j+36AJqG J0iAxhNEjmA5td5uW14lFDQTalLqyAsDvRa5LfyWBSjNgYJLu/Lpvj5Wq+aB3lDx XtZeQgAqMeZcilLRJsM/L1cqZZVM2G/PvKOeL87qSH9sVcbPh+dY3687f/3U9pz+ TT2IZQWoLJoB+XFyazJ90UZPNzXD8s0KpR2hiE3zBsu19YjdF2NiNIVGUgiU5CBc MiQCmzOopIc912u4p5Bq4K71/J+ozrF/SI6tplIPABiyAeVQRktQ0UySGYyKWN5H yKKUOB22BXAB03c9ZVqvWegBRTAE03lZc7dnKifoZLcMNT7gLJOS7cw0Ot0IhHG8 G5/8V6DiSncq/ZHHqrdwe/nfH8b3GWDvpYdrpXq4U/nrd7Tm5gOpwjTsH7bFIGDc iqOp95Ki6Gnq3VuTqZmvRlPqRadweod4uLzalm2EKGzw4xl781olmC6t+W2sj0Gn ab9gCGc06QN+vihP9quOgkL9h+ugZMG6IYDQ1ikK5QKxmRoBBrT0JS6OxVn0nvl1 eBqHF0nOoRdRcnMrFx4tY9vvNu1xkQ35BOs8oIxXrpE4qvt1JCpgwkI1KnqlPGc9 G0ADOddDXy2iMn1CX7RZ =tepS -----END PGP SIGNATURE----- --=-=-=--