[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tvlo2iv0.wl-kuninori.morimoto.gx@renesas.com>
Date: Sun, 14 Oct 2018 23:53:24 +0000
From: Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
To: Stephen Boyd <sboyd@...nel.org>
Cc: Mark Rutland <mark.rutland@....com>,
Michael Turquette <mturquette@...libre.com>,
Rob Herring <robh+dt@...nel.org>, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] clk: add 74aup1g157gw 2-input multiplexer as clock driver
Hi Stephen
> > > > + .recalc_rate = clk74_recalc_rate,
> > > > + .get_parent = clk74_get_parent,
> > > > +};
> > >
> > > Can this all be handled by the 'gpio-mux-clock' compatible/driver? I
> > > suppose it may need an update to add the rounding policy that you want
> > > via some sort of DT property, but otherwise it would be fine?
> >
> > Hmm.. not sure.
> > If we can add new feature (= .round_rate ?) on gpio-mux-clock,
> > I can consider it.
>
> Yes that would be the idea. Extend gpio-mux-clock driver to have what
> you want with rounding. I'm not really sure why there is a rounding
> policy needed though. Is it a static configuration at boot, or does the
> code using this gpio clk need to search the parent rate space somehow
> and mux it over?
Thank you for pointing gpio-mux-clock.
I tried to use it, and it works well instead of new driver.
Actually, it is not 100%, but it should be solved sound side,
not clock side, I think.
But anyway, this driver is no longer needed, please drop it.
Thank you very much
Powered by blists - more mailing lists