[PATCH RFC 0/3] clk: CCF clock primitives + custom IO accessors

[Gerhard Sittig]

On Fri, Feb 28, 2014 at 15:34 -0800, Soren Brinkmann wrote:
> 
> [ MMIO registers assumed for clock control modules, but I2C
> communication may be involved in other hardware, individual for
> a (set of) clock(s) and not for an architecture or platform ]
> 
> Does anybody have a good idea how we could avoid all this code
> duplication while enabling usage of the clock primitives with different
> IO accessors?
> Especially the divider and mux primitive have a lot of code that would
> be painful to maintain twice.

Hasn't past discussion already reached the point where code
duplication of the clock control logic was considered
undesirable, and "low level ops" were outlined?  I.e. extending
the compile time decision for a specific clk_{read,write}l()
implementation by another potential redirection that is specific
to a clock item?

Re-submitting a series which duplicates complete clock types,
while the difference is only in how registers get accessed, is
quite saddening.


> In the next step, I encountered a divider clock whose divider is stored
> in 2 I2C registers. So now, the simple IO access replacement doesn't
> work anymore either since this clock needs 2 registers to be read and
> then shifting around the bitfields accordingly.

Are the registers adjacent and contain only bit fields for one
clock?  Or do registers share parameters for several clocks, or
are not adjacent?

In the former case you may use a table from "divider value" to
"bit pattern to read/write".  In the latter case, the clock
control module is rather special, and may not be easily get
mapped to the common primitives.  Unless the ll_ops can implement
the required special handling.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de