Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 11 Mar 2019 11:28:25 +0100
From:   Sascha Hauer <s.hauer@pengutronix.de>
To:     Abel Vesa <abel.vesa@nxp.com>
Cc:     Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Sascha Hauer <kernel@pengutronix.de>,
        Lucas Stach <l.stach@pengutronix.de>,
        Shawn Guo <shawnguo@kernel.org>,
        Aisheng Dong <aisheng.dong@nxp.com>,
        Jacky Bai <ping.bai@nxp.com>,
        Anson Huang <anson.huang@nxp.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        dl-linux-imx <linux-imx@nxp.com>,
        Fabio Estevam <fabio.estevam@nxp.com>,
        "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC] clk: imx: Allow re-parenting by default on set rate
Message-ID: <20190311102825.g7d5mmorcltxnnzf@pengutronix.de>
References: <1551950425-7346-1-git-send-email-abel.vesa@nxp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1551950425-7346-1-git-send-email-abel.vesa@nxp.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Abel,

On Thu, Mar 07, 2019 at 09:20:37AM +0000, Abel Vesa wrote:
> By default, the muxes should re-parent on set_rate.
> This would allow the drivers to control only the leaf clock node,
> leaving the rest to the clock driver, that way simplifying the
> clock control.

I am afraid of this change. Besides the rate there might be other
reasons to choose one mux input over another, consider for example low
power audio playback where we need one specific mux setting because it
provides a clock which runs at low power mode.
On the IPU on i.MX5/6 there are clocks being used as pixel clocks
derived from different muxes. I don't think you want to pick an input
clock just because it happens to deliver the best clock rate at that
point in time, but really is shared with some other clock that changes
its rate in the next moment.

I have no concrete examples for things that break with this change, but
I would be more confident if we change the behaviour explicitly only for
the muxes that we have reviewed to cope with this change.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |