From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753289AbcEBIym (ORCPT ); Mon, 2 May 2016 04:54:42 -0400 Received: from 212-186-180-163.dynamic.surfer.at ([212.186.180.163]:52894 "EHLO cgate.sperl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753258AbcEBIye (ORCPT ); Mon, 2 May 2016 04:54:34 -0400 Subject: Re: [PATCH 2/2] clk: bcm2835: Skip PLLC clocks when deciding on a new clock parent To: Eric Anholt References: <1461699585-6649-1-git-send-email-eric@anholt.net> <1461699585-6649-2-git-send-email-eric@anholt.net> 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 , "devicetree@vger.kernel.org" From: Martin Sperl Message-ID: <572715C5.6070700@sperl.org> Date: Mon, 2 May 2016 10:54:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30.04.2016 11:28, Martin Sperl wrote: >> On 26.04.2016, at 21:39, Eric Anholt wrote: >> >> 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. >> >> 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. >> >> Signed-off-by: Eric Anholt >> Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") >> — > I guess this patch looks to me as if it is a policy inside the kernel, > which is AFAIK frowned upon. > > I am looking into making "assigned-clock-parents” inside the dt > work with the driver. > > Could look something like this: > i2s: i2s@7e203000 { > assigned-clock-parents = <&cprman BCM2835_PLLD_PER>, <&clk_osc>; > assigned-clocks = <&cprman BCM2835_CLOCK_PCM>, <&cprman BCM2835_CLOCK_PCM>; > }; > (not sure if that works really - the same clock in assigned-clocks looks suspicious) > > This would move the policy out of the kernel into the device-tree, > which - i guess is a better solution. So after some more investigation it seems that we can not really use those assigned-clock-parents properties for our purpose of filtering the parent clocks, as it: a) requires also assigned-clocks to be set (this may be OK) b) it does not allow to define a list of clocks to get used - it will just set the parent of the assigned-clock - if we take the example shown above, it would call clk_set_parent 2 times for the PCM clock - once with PLLD_PER and once with clk_osc. So I start to wonder if it would not be better to use an approach like this: cprman: cprman@7e101000 { ... brcm,clock-flags = , ; brcm,clock-index = , ; } the flags would be a bitfield that select the parent clocks. So it could look like this: cprman: cprman@7e101000 { ... brcm,clock-flags = (BIT(BCM2835_PER_PARENT_OSC) | BIT(BCM2835_PER_PARENT_PLLD_PER)), ...; brcm,clock-index = , ; } BCM2835_PER_PARENT_PLLD_PER and BCM2835_PER_PARENT_OSC would then be defined in include/dt-bindings/clock/bcm2835.h In addition this would also allow us to add other flags to enable higher order MASH clock dividers - we currently only allow simple fractional dividers - we could even force the use of integer dividers if there comes a need. This would really allow us to define the parents freely and if the firmware ever changes its behavior with regards to PLLC, then we can easily change the device-tree. Is this approach acceptable - maybe in a variation? Thanks, Martin