Re: [PATCH 4/5] clk: sunxi-ng: Add driver for A83T CCU

[Stephen Boyd]

On 02/15, Maxime Ripard wrote:
> On Tue, Feb 14, 2017 at 06:26:39PM +0800, Chen-Yu Tsai wrote:
> > On Tue, Feb 14, 2017 at 5:58 PM, Maxime Ripard
> > <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote:
> > > On Tue, Feb 14, 2017 at 11:35:25AM +0800, Chen-Yu Tsai wrote:
> > >> +/*
> > >> + * MMC2 supports what's called the "new timing mode". The CCU and the MMC
> > >> + * controller must be in sync about which mode is used. The new mode moves
> > >> + * the clock delay controls (and possibly the delay lines) into the MMC
> > >> + * block. Also, the output of the clock is divided by 2. The output and
> > >> + * sample phase clocks are unused under this mode.
> > >> + *
> > >> + * This new mode seems to be preferred. Hence we force this clock to the
> > >> + * new mode. And we don't add the phase clocks.
> > >> + */
> > >
> > > I'm sorry, but I said this several times, this isn't working. We
> > > should model it properly, and not hack this around in the clock
> > > driver.
> > >
> > > As you say in your comment, the MMC driver needs to be aware about
> > > which mode is used, in order to also set a bit in one of its registers
> > > accordingly, and modify its sampling behaviour.
> > >
> > > The new timing is preferred, but our previous clock implementations
> > > didn't hardcode it, so we can't even rely on that behaviour to always
> > > write it in our driver.
> > 
> > Correct. With the A83T there has never been a merged clock driver though.
> > I realize this is a one off thing.
> > 
> > > This is not something specific to the A83T, but is found in all the
> > > SoCs since the A23, so we need to come up with a good solution to
> > > address that.
> > >
> > > I'm not sure what a good solution would be though. One would be to
> > > just have a private function of our own to switch in the new mode (if
> > > relevant, because only the MMC2 controllers have it), but that would
> > > lead to troubles with !sunxi-ng. Not something we can't deal with, but
> > > some extra precautions should be taken (make sure to protect the call
> > > through an ifdef / IS_DEFINED, check that the sunxi-ng driver has been
> > > probed, etc.)
> > 
> > If the custom function route is acceptable, I'll come up with something.
> 
> I think it would be a great start yes. I'll try to discuss it with
> Mike and Stephen at ELC and see what they think about that.
> 

I didn't hear anything at ELC. Can someone explain what the issue
is? Could something like clk_get_phase() + clk_get_rate() tell us
if we're in one mode vs. the other?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project