On Thursday 02 October 2008, Hiroshi DOYU wrote:
> For some of the above drivers, omap's "functional clock" and
> "interface clock" doesn't make sense.
Actually, I thought OMAP was pretty consistent about having
both on all modules where it made sense.
> For such device drivers, those
> clocks may look just a single necessary clock and there's no "one to
> one" correspondence from the omap clock functionality definitions
> ("ick"/"fck") perspective.
They're all OMAP-specific drivers. They can know that they
need to ask for both clocks. If perchance only one of them
were actually needed, that would be exceptional ... and the
driver should be able to assume the device was properly
set up, and continue without it.
> I think that this is one of the examples,
> where the flexibily is required. Since required functionaliies for
> clocks depends on each device drivers, I think that it would give a
> wider solution to let device drivers to define their logical
> clocks(functionality) flexibly(not 1-to-1), rather than statically
> pre-defined standardized functional names, which is the 1-to-1
> correspondence of ick and fck in the TRM with aliasing.
The ICK/FCK example is not IMO persuasive; this is OMAP, so
the assumption can be that all drivers have both.
Having the clocks set up by clk_associate() would suffice
for most devices and drivers. Are there ones where that's
not enough ... where a device needs more than those "logical"
clock identifiers?
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
