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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
