From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934185AbcECBJb (ORCPT ); Mon, 2 May 2016 21:09:31 -0400 Received: from anholt.net ([50.246.234.109]:44077 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933585AbcECBJ2 (ORCPT ); Mon, 2 May 2016 21:09:28 -0400 From: Eric Anholt To: Martin Sperl Cc: Michael Turquette , Stephen Boyd , linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Stephen Warren , Lee Jones Subject: Re: [PATCH 2/2] clk: bcm2835: Skip PLLC clocks when deciding on a new clock parent In-Reply-To: References: <1461699585-6649-1-git-send-email-eric@anholt.net> <1461699585-6649-2-git-send-email-eric@anholt.net> <878tzsiilh.fsf@eliezer.anholt.net> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 02 May 2016 18:09:22 -0700 Message-ID: <87zis8uev1.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable Martin Sperl writes: >> On 02.05.2016, at 17:29, Eric Anholt wrote: >>=20 >> Martin Sperl writes: >>=20 >>>> On 26.04.2016, at 21:39, Eric Anholt wrote: >>>>=20 >>>> If the firmware had set up a clock to source from PLLC, go along with >>>> it. But if we're looking for a new parent, we don't want to switch it >>>> to PLLC because the firmware will force PLLC (and thus the AXI bus >>>> clock) to different frequencies during over-temp/under-voltage, >>>> without notification to Linux. >>>>=20 >>>> On my system, this moves the Linux-enabled HDMI state machine and DSI1 >>>> escape clock over to plld_per from pllc_per. EMMC still ends up on >>>> pllc_per, because the firmware had set it up to use that. >>>>=20 >>>> Signed-off-by: Eric Anholt >>>> Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the au= dio domain clocks") >>>> =E2=80=94 >>>=20 >>> I guess this patch looks to me as if it is a policy inside the kernel, >>> which is AFAIK frowned upon. >>=20 >> Can you come up with a use for putting peripherals on PLLC ever, such >> that we need choice? > > For PLLC not right now, but with clk_notifier_register drivers could > work around those clock changes (assuming we get that information > from the firmware somehow - or if we could move this decision into the > kernel: even better). Why would you want to automatically choose an unstable clock instead of the stable clock we have available? > But I can come up with a scenario that would make use of the pllh_aux > under some circumstances - e.g when requesting 290039Hz on clock gp0/1/2. > > Similarly: if we ever enable the testdebugX clocks these become immediate > candidates for parent-clocks as well which can result in more headache. How are you planning to make use of the testdebug inputs? As far as I know, those are for bit-banging your clocks during hardware bringup debugging. They wouldn't be clocks you'd automatically choose. > Being able to define which clocks to use at least give the dts author > a means also to control clock selection if he wants to enable the > testdebug clocks. If you were to clock-assigned-parents something to PLLC, this code won't override that. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJXJ/pCAAoJELXWKTbR/J7ojbYQALJAqXIk/1329r7vCbqh5pIZ /10wkwhgEEiziKftEHa+KNKRmecQ8KyFnB3ZlZvDlVmYjjNMmFMyzr6FoqKSepuK FmqxnSThu60w8dDqYaqZwr3U7tCwe1riIi7N7QmWde10I2XbNfQw0y3lb6NEtPT6 l2MkRuIXIIUpNgsnT0M99m5VKXmZXQw0Pj+VRVc7Ldf/i5/ZMm3Lou0wnQuluqDG ilc7TlUKpKBft+Ix6qK18h20awkFc2yVtAN/A+SNMpd9OSya6RT9ntYoW/TVpKXZ B67xYYdQ7R5IlL7mhGcqKHH3hj1oS7R8V9WQJcb5BnqMgsiYtlreyT8RURf6pFHm JBq8XbZsXJ6eqkm6VpTDa234ESNUWt1MO/u1/8bE5gHrOeZUuuoUTqOlKBGsR6L+ ZnLtboBHLY5n8TZWUuxQ8yU7yHwpNBIVbHUv/B/KXfBPVQAWBTL6HP4mIThqwYK+ o5oyhMb+jl7+SGim23rg2eInxjS3EMouxj75zpVgglYH6fssTOHzqIFRvfqg21cn oiAHsmv1YPxSjUnem92dKL7GGJzUpN0MNBg1lYRN+R9J8LkX8yG6tsHeTJNmMQNE Or/3Lt0hTBpWP2m1jwdLHfspb3nWN+wk1F2ujffD95eTlhFQbSPndLfIzVO4PxKn VRquUK0cXcynttbCbxmT =Uv1y -----END PGP SIGNATURE----- --=-=-=--