Re: [PATCH 3/3 v3] mmc: sh_mmcif: calculate best clock with parent clock

[Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>]

Hi Laurent

> > > +struct sh_mmcif_parent_clk {
> 
> I'm not sure I would call this parent clock. It refers to the frequency of the 
> functional clock provided to the MMCIF, there's no concept of parent there. 
> True, the clock referenced by the MMCIF DT node is an MSTP gate clock, and 
> frequency control is implemented in the MSTP clock parent, but that hardware 
> architecture is internal to the CPG and shouldn't be considered by the MMCIF.

I couldn't understand about last 2 lines.
Do you mean I need to add these method in CPG ?
But, this calculates best clock of parent clock (= from CPG) and divider (= on MMC)
Why CPG need to care about MMC's divider,
and how to set it from CPG ??

> > Shouldn't this come from private data in the CPG clock driver, which
> > supplies the parent clock? Then the mmcif driver will be independent from
> > the parent clock.
> 
> The real question is where the constraint comes from. The Gen2 datasheet 
> documents the MMC clocks maximum frequency as 97.5 MHz in the CPG section. 
> However, I have a feeling the constraint doesn't come from the DIV6 which 
> should be able to output higher frequencies, but from the MMCIF, the clock 
> distribution tree, or both.
> 
> There's also the option of specifying the admissible clock range in DT, either 
> in the CPG node or the MMCIF node.

It needs not only max/min range, but also divider's limit.
I don't know how to do it. but...

 1) add admissible max/min range on CPG node
    add admissible divider range on MMC node
     -> Does this max/min range really from CPG ?
        but, we can reuse this on other DIV6

 2) add admissible max/min range on MMC node
    add admissible divider range on MMC node
     -> reasonable, but we can't reuse it on other DIV6
        what is difference between 2) and 3) ?

 3) add admissible max/min range on MMC driver
    add admissible divider range on MMC driver
     -> This is the reason why we have SoC specific compatible name ?
        These limit came from SoC.

In my opinion, I can accept 1) or 3).

Best regards
---
Kuninori Morimoto