Hi Morimoto-san,
Sorry for the late reply.
On Wednesday 22 April 2015 01:05:59 Kuninori Morimoto wrote:
> 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 ??
No, that's not what I meant. The CPG should certainly not care about any MMCIF
internal divider.
My point was about the name of the structure. However, now that you mention
the internal MMCIF clock divider, the word "parent" indeed makes sense. Please
ignore my comment.
> >> 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).
Once again it really depends where the constraints come from. If the MMC input
clock frequency range constraint is dictated by the MMCIF IP core only,
options 2 and 3 are equivalent and just differ by whether they specify the
range explicitly in DT (option 2) or implicitly through the compatible name
(option 3).
If the range constraint comes from the CPG, option 1 is the way to go,
(although the admissible divider range could also be speficied in the MMC
driver as in option 3).
If the range constraint is a property of the integration of the MMCIF in the
SoC then I think option 2 is the best. The per-SoC compatible strings can be
used to express differences between IP core versions found in different SoCs,
but they shouldn't be used to express integration properties.
To clarify this with an example, it's fine for the DU driver to use the per-
SoC compatible string to know how many display channels the DU contains, but
it can't be used to hardcode IRQ numbers in the driver, even if we know which
IRQ the DU is hooked to for each SoC. The former is a property of the DU
version, the latter is a property of the integration and should be expressed
in DT.
--
Regards,
Laurent Pinchart
--
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
